Tulina

github_actions

GitHub Actions — workflows, runs, jobs, logs and artifacts.

Read first: runs then jobs then logs is the normal path to understand why a pipeline failed.

⚠️ Read status AND conclusion: a completed run may have failed, and conclusion stays null while the work is not finished.

⚠️ op='dispatch' triggers a real run — thus potentially a build, a publication or a deployment. It is dry-run by default: dry_run=false to really trigger. The workflow must declare workflow_dispatch, otherwise GitHub answers 404 — here a 404 means "not triggerable", not "does not exist". The response does NOT return the created run: find it by listing the runs right afterwards (there is a short delay).

⚠️ rerun reruns the WHOLE run (billed minutes, possible redeployment); rerun_failed only replays the failed jobs — cheaper and less risky. cancel interrupts work in progress.

⚠️ logs and download return an ephemeral signed URL (~1 minute), to be downloaded without an authentication header — the storage refuses a doubly authenticated request. None signals expired logs or a stale artifact (90 days by default).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "github_actions"
  }
}

Input Schema

Name	Required	Description	Default
`op`	No	the operation, see above.	runs
`ref`	No	op='dispatch' — the branch or tag to run on.
`_org`	No	Org (id) de CET APPEL. `oto_list_orgs()`.
`page`	No	page number.
`repo`	No	repository name.
`actor`	No	op='runs' — filter by triggering actor.
`event`	No	op='runs' — filter by triggering event.
`owner`	No	repository owner.
`_group`	No	Équipe (id) de CET APPEL, sous son org parente.
`branch`	No	op='runs' — filter by branch.
`inputs`	No	op='dispatch' — the workflow's inputs.
`job_id`	No	the targeted job (job, logs).
`run_id`	No	the targeted run.
`status`	No	op='runs' — queued \| in_progress \| completed \| success \| failure…
`_run_id`	No	OBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
`dry_run`	No	op='dispatch' — True (default) describes without triggering.
`_account`	No	Compte à OPÉRER parmi : `Julien` (org), `Tulina front` (org). `oto_identity(op='list')`.
`_project`	No	Projet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
`per_page`	No	rows per page (1-100, default 30).
`workflow`	No	numeric id or file name (ci.yml) — the name is more stable.
`_instance`	No	Instance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
`artifact_id`	No	the targeted artifact (artifact, download, delete_artifact).

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.1/5.0

Behavior5/5

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

With no annotations supplied, the description carries the full behavioral burden and does so thoroughly: dispatch performs a real trigger that may build, publish or deploy, is dry-run by default, requires `workflow_dispatch` (404 = 'not triggerable, not missing'), and does not return the created run. It also discloses that `logs`/`download` return a ~1-minute signed URL that must be fetched without an auth header, and that `None` means expired logs or a >90-day stale artifact — all non-obvious traits beyond 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.

Conciseness4/5

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

The layout is strongly front-loaded: the read-path heuristic comes first, then the risk warnings in descending severity. Almost every sentence earns its place, but the `op` schema field says 'see above' while the description never actually enumerates the operations, leaving a dangling reference, and the warning blockquotes slightly obscure the simpler read operations.

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

Completeness3/5

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

For a 22-parameter, 16-operation mutation-capable tool with no annotations and no output schema, the description covers the dangerous half (dispatch, rerun, cancel, logs, download) very well but is silent on `workflows`, `workflow`, `run`, `job`, `artifacts`, `artifact`, `delete_run` and `delete_artifact` — notably the two destructive deletes, whose reversibility and consequences are never stated. An agent can safely trigger a deployment but has no comparable footing on deletion.

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 description coverage is 100%, so the baseline is 3; the description still adds real meaning by clarifying the `status` vs `conclusion` distinction (a `completed` run can have failed; `conclusion` is null while work is unfinished) and by explaining dispatch's `ref`, `inputs` and `dry_run` interplay. It does not add semantic color to the tenancy parameters (`_org`, `_project`, `_instance`, `_run_id`), which are left entirely to the schema.

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 first line names the resource family precisely (workflows, runs, jobs, logs, artifacts) and the `op` enum in the schema enumerates the 16 operations, so an agent knows this is the GitHub Actions surface. It does not explicitly differentiate itself from nearby siblings such as `github_act` or `github_repos`, so an agent must infer the boundary from the resource nouns alone.

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 gives an explicit diagnostic path — 'runs then jobs then logs is the normal path to understand why a pipeline failed' — and states the selection rule between `rerun` (whole run, billed, redeploy) and `rerun_failed` (failed jobs only, cheaper). What is missing is guidance on when to reach for this tool versus `github_act` or `github_repos`, and no exclusions are stated.

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

All Tulina tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?