Skip to main content
Glama
brechanbech

forgejo-mcp-rs

by brechanbech
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Remote

Get commit statuses

get_commit_statuses
Read-only

List every status reported against a commit, branch, or tag, including each check’s context, state, and target URL, to inspect CI history; use get_combined_status for a single pass/fail verdict.

Instructions

List the statuses reported against a commit, branch or tag (owner/repo/ref): each check's context, status (success, pending, failure, error, warning), description and target_url. Every transition is recorded, so one ref carries a history rather than a state: the same context appears as 'Waiting to run', then 'In progress', then its result. The newest entry per context is the current verdict — for "did CI pass?" call get_combined_status instead, which returns one state with the latest per check. Neither Forgejo nor Gitea exposes a logs API, so target_url is often the only route to a failing run's detail; both return it relative to the instance origin, so prefix the host before following it. Creator and timestamps beyond updated_at are dropped.

Input Schema

NameRequiredDescriptionDefault
refYesThe commit, branch or tag whose statuses to read.
pageNo1-based page number.
repoYesRepository name.
limitNoResults per page.
ownerYesRepository owner — user or organization.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.22.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only cover read-only/open-world; the description adds substantially beyond them: results are append-style history rather than current state, the newest entry per context is the verdict, target_url is origin-relative and must be prefixed, and creator/timestamps are dropped. That is exactly the context annotations can't carry.

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?

Front-loaded with the action, then the return shape, then the alternative-tool routing, then caveats. Every sentence carries operational information — even the closing note about dropped fields prevents a wrong expectation about the payload.

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 no output schema, the description still enumerates the returned fields, explains the history-not-state semantics that would otherwise cause misinterpretation, and warns about the relative target_url. An agent can call and interpret this correctly without further context.

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?

Schema description coverage is 100%, so baseline is 3. The description elaborates on `ref` (commit, branch or tag) and the owner/repo/ref path shape, but `page` and `limit` are left entirely to the schema, so no value is added beyond structured data.

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?

States a specific verb plus resource ('List the statuses reported against a commit, branch or tag') and immediately names the fields returned per entry. It explicitly distinguishes itself from get_combined_status, a sibling that would otherwise look interchangeable.

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 routing rule with the exact question it answers — 'for "did CI pass?" call get_combined_status instead' — and explains why (per-check history vs one latest state). It also tells the agent when this tool is the only route to detail (no logs API; follow target_url).

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

Deploy Server

Other Tools