Git for Me!
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GITHUB_TOKEN | No | Optional fine-grained GitHub token (no permissions required) that raises the GitHub search rate limit from 10 to 30 searches per minute. Pass it as GITHUB_TOKEN; it is sent to GitHub alone. |
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 |
|---|---|
| git_for_meA | Step 1 of 3, before recommending any open-source repo or writing something that might already exist. If stack, platform, license or upkeep is missing, returns the questions to ask the user first: call again with the answers ("unknown" is fine). Then returns the method: split what the user wants to build into parts, search GitHub, GitLab and Codeberg for each with git_for_me_search, and decide from what it finds which parts an existing repo covers (use it as is or adapt it), which nothing covers (build it), and which are not worth a dependency (write them). Follow it. |
| git_for_me_searchA | Step 2 of 3: searches for each part: on GitHub the topic's most starred and rising repos, names and descriptions holding each keyword, and README text; on GitLab and Codeberg the topic and the keywords. Returns what it found, with stars, license, language, last activity and how each turned up, to pick each part's verdict and candidates from. Then call git_for_me_verify. |
| git_for_me_verifyA | Step 3 of 3: checks every picked repo live on its forge, drops the ones that are not there, flags no license, copyleft, archived, stale, little used, forks and mirrors, marks picks the search didn't turn up as from memory, shows what it found that wasn't picked, and returns the report to show the user. If nextAction is SEARCH_FIRST or RECALL_REPLACEMENTS, do what its instructions say and call again. |
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
The three tools form a clear 1-2-3 sequence with distinct roles (plan, search, verify), and descriptions explicitly state the step order. However, the names are very similar and the base tool name 'git_for_me' doesn't convey its planning role, so an agent might misselect without reading descriptions.
All tools use snake_case and share the 'git_for_me' prefix, following a predictable pattern. The base tool lacks a verb suffix while the others have '_search' and '_verify', which is a minor inconsistency.
Three tools map exactly to the three-step workflow, each earning its place with a distinct function. The count is well-scoped for the server's narrow decision-support purpose.
The surface covers requirements elicitation, multi-forge search, and live verification, which is complete for helping users decide on existing repos. No obvious gaps or dead ends in the workflow.