standup-mr
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GITHUB_HOST | No | GitHub API host. Defaults to github.com when using GitHub. | |
| GITLAB_HOST | No | GitLab API host (e.g., gitlab.com or a self-hosted instance). | |
| GITHUB_TOKEN | No | GitHub personal access token for authenticated API access. | |
| GITLAB_TOKEN | No | GitLab personal access token for authenticated API access. | |
| STANDUP_PROVIDER | No | Provider to use when it cannot be inferred from the environment. Values: 'github' or 'gitlab'. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_standup_dataA | Collect merge-request-based standup data from GitLab or GitHub. Returns one JSON object: 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 |
| post_standup_noteA | Posts a finished standup note to a chat webhook. This one has a side effect: it sends a message other people will see, so only call it on a note the user has agreed to send. The webhook URL is read from STANDUP_WEBHOOK_URL, never from an argument — a webhook URL is a credential, since anyone holding it can post to the channel. Slack and Discord payload shapes are supported; the shape is inferred from the URL host, and |
| get_note_instructionsA | Returns the note-writing rules — the playbook for turning get_standup_data output into a standup note a person would actually say out loud: how to group the previous day by theme, how to derive today from open merge requests, and how to report a blocker from its job log. Read-only, no arguments, no network. Call it once before writing the first note; the rules do not change between calls. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a clear, non-overlapping role: fetching standup data, fetching note-writing instructions, and posting the final note. There is no ambiguity about which tool to use for a given step.
All tool names follow a consistent get_/post_ verb-noun pattern in snake_case, with nouns clearly indicating the resource ('standup_data', 'note_instructions', 'standup_note'). The naming is predictable and readable.
With exactly three tools, the server is tightly scoped to a single workflow: retrieve data, retrieve instructions, and post the result. Each tool is necessary and earns its place; there are no redundant tools.
The tool surface fully covers the stated purpose of generating and posting a standup note: instructions, data, and posting are all present. The snapshot description clarifies intentional limitations, and there are no dead ends in the workflow.