Skip to main content
Glama

Get a workflow run

get_workflow_run
Read-only

Fetch one Actions workflow run by owner, repo, and run_id to inspect its status, event, workflow, ref, commit SHA, URL, and timestamps.

Instructions

Get one Actions workflow run by run_id (owner/repo/run_id), in list_workflow_runs' shape on both forges: status (the outcome once there is one), event, workflow, ref, commit_sha, html_url and timestamps. For its jobs and logs use list_workflow_jobs and get_job_log.

Input Schema

NameRequiredDescriptionDefault
repoYesRepository name.
ownerYesRepository owner — user or organization.
run_idYesWorkflow run id (the `id` field from `list_workflow_runs`).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.22.0

TDQS

A4.2/5.0
Behavior4/5

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds useful return-shape context and a subtle caveat that status is 'the outcome once there is one,' but it does not describe error behavior when a run is missing.

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

Conciseness5/5

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

Two tightly packed sentences with no waste. The core operation is front-loaded, followed immediately by the return shape and the related-tool routing.

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 does a good job naming the returned fields and referencing list_workflow_runs for the shape. It omits some detail such as pagination or not-found behavior, but those are minor for a single-resource read tool.

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

Parameters3/5

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

The schema has 100% description coverage for owner, repo, and run_id, so the parameter documentation burden is already met. The description adds only the owner/repo/run_id grouping and a reminder that run_id comes from list_workflow_runs, which is already in the schema.

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?

The description gives a specific verb and resource: 'Get one Actions workflow run by run_id.' It also clarifies the shape by naming list_workflow_runs and enumerating returned fields, which distinguishes this single-run getter from the list-oriented sibling.

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?

It explicitly routes the agent to list_workflow_jobs and get_job_log for jobs and logs, which is strong when-not guidance for related data. It does not explicitly state when to use this rather than list_workflow_runs, though 'one ... by run_id' makes that boundary clear enough.

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