Skip to main content
Glama

Get standup data

get_standup_data
Read-onlyIdempotent

Collects GitLab or GitHub merge/pull request data for daily standup notes, grouping today's MRs, prior-day events, reviews waiting on you, and blockers with failed-pipeline error lines.

Instructions

Collect merge-request-based standup data from GitLab or GitHub. Returns one JSON object: today, previousDays[] with the events of each, todayEvents[], myMrs[] bucketed ready / blocked / draft / stale, reviews[] waiting on you, and blockers[] carrying the error lines read out of each failed pipeline job log.

Call it once at the start of a working day, to write a standup note. It is a snapshot, not a search API: it cannot fetch one named merge request, reach further back than the previous working day, or filter by project.

Read-only, and credentials never come from an argument — they come from the environment or a logged-in gh / glab session. A rejected token, a refused resource or a rate limit fails the call with the host's own message, after two retries on transient server errors. A blocker whose diagnosis could not be fetched is still returned, with job: "unknown", so a red pipeline is never silently dropped.

Input Schema

NameRequiredDescriptionDefault
hostNoSelf-hosted host, without a scheme, e.g. gitlab.example.com or github.example.com. Required for GitLab, which has no default host; optional for GitHub, which defaults to github.com. A recognisable host also settles `provider` on its own, so the two are rarely both needed.
langNoLanguage for the date labels inside the returned JSON: en (default) or tr. It relabels dates and nothing else — no field is translated, and the standup note itself is written by the caller, in whatever language they are speaking.
providerNoWhich provider to read. Omit to auto-detect, in this order: a recognisable host, STANDUP_PROVIDER, a GITHUB_*/GITLAB_* environment pair, then whichever of the gh / glab CLIs is logged in. Pass it when both are configured — ambiguity fails the call rather than being guessed at.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.4.1
    • changedInput schema / properties / host / description
      Previous value: -"Self-hosted host, without a scheme, e.g. gitlab.example.com or github.example.com. GitHub defaults to github.com; GitLab has no default, so self-hosted GitLab needs this or GITLAB_HOST."New value: +"Self-hosted host, without a scheme, e.g. gitlab.example.com or github.example.com. Required for GitLab, which has no default host; optional for GitHub, which defaults to github.com. A recognisable host also settles `provider` on its own, so the two are rarely both needed."
    • changedInput schema / properties / lang / description
      Previous value: -"Language for the date labels inside the returned JSON. Defaults to en. Only the labels change — the standup note itself is written by the caller."New value: +"Language for the date labels inside the returned JSON: en (default) or tr. It relabels dates and nothing else — no field is translated, and the standup note itself is written by the caller, in whatever language they are speaking."
    • changedInput schema / properties / provider / description
      Previous value: -"Which provider to read. Omit to auto-detect, in this order: a recognisable host, STANDUP_PROVIDER, a GITHUB_*/GITLAB_* environment pair, then whichever of the gh / glab CLIs is logged in."New value: +"Which provider to read. Omit to auto-detect, in this order: a recognisable host, STANDUP_PROVIDER, a GITHUB_*/GITLAB_* environment pair, then whichever of the gh / glab CLIs is logged in. Pass it when both are configured — ambiguity fails the call rather than being guessed at."
  2. Changed3 schema fields changedv0.1.1
    • addedInput schema / properties / host
      Added value: +{
      +  "description": "Self-hosted host, without a scheme, e.g. gitlab.example.com or github.example.com. GitHub defaults to github.com; GitLab has no default, so self-hosted GitLab needs this or GITLAB_HOST.",
      +  "type": "string"
      +}
    • addedInput schema / properties / lang
      Added value: +{
      +  "description": "Language for the date labels inside the returned JSON. Defaults to en. Only the labels change — the standup note itself is written by the caller.",
      +  "enum": [
      +    "en",
      +    "tr"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / provider
      Added value: +{
      +  "description": "Which provider to read. Omit to auto-detect, in this order: a recognisable host, STANDUP_PROVIDER, a GITHUB_*/GITLAB_* environment pair, then whichever of the gh / glab CLIs is logged in.",
      +  "enum": [
      +    "github",
      +    "gitlab"
      +  ],
      +  "type": "string"
      +}
  3. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond annotations: credentials come from the environment or a gh/glab session and never from an argument, failures (rejected token, refused resource, rate limit) surface the host's own message after two retries on transient server errors, and a blocker whose log could not be read is still returned with job: "unknown" so failures are never silently dropped. This is exactly the operational context an agent cannot get from readOnlyHint/openWorldHint.

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-loads what it collects and returns, then usage, then behavior; each sentence carries information. The return-shape enumeration is long, but it substitutes for a missing output schema, so it largely earns its space.

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 supplies the return structure, and it covers auth sourcing, retry policy, error surfacing, and degraded-output behavior. Nothing an agent needs to call this correctly appears to be missing.

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%, and each of host/lang/provider is fully documented in the schema, including auto-detection order and enum values. The description adds only the tangential note that credentials are not a parameter, so baseline 3 is appropriate.

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 and resource (collect merge-request standup data from GitLab/GitHub) and enumerates the returned buckets (today, myMrs ready/blocked/draft/stale, reviews, blockers). This clearly separates it from the sibling post_standup_note, which writes rather than reads.

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 when ('Call it once at the start of a working day, to write a standup note') and explicit when-not ('it cannot fetch one named merge request, reach further back than the previous working day, or filter by project'). The boundaries of the tool are stated rather than left to inference.

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