readfirst
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| read_listB | What to read and check before changing these files: the project rules and risks that apply, the checks to run, the tests that reach the code and the files that use it. Call it before editing. |
| changed_read_listA | The same read list for every file changed on this branch since the base (default origin/main, else main). Call it before finishing, then run the checks it lists. |
| find_existingA | Before writing a new function, helper or module: the functions, classes, files and map entries that may already do it, matched by words (not meaning) against names and paths. Give a few words about what it does, e.g. "payment retry" or "csv export". If one fits, use or extend it instead of writing another. |
| check_mapA | Whether .readfirst/map.json still covers the code: files in no group, patterns that match nothing, broken rules. |
| audit_repoA | The whole repository against .readfirst/map.json, as a report: rules and risks whose files changed a lot since they were written, hot spots that moved, groups never filled in, code no test reaches through imports, and what readfirst could not see. Use it before larger work, or to decide what to add to the map. |
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 5 tools
Tools are largely distinct: find_existing searches for existing code, read_list prepares edits for given files, changed_read_list does the same for branch changes, check_map validates map coverage, and audit_repo reports repo-wide issues. The only mild overlap is read_list vs changed_read_list and audit_repo vs check_map, but their scopes are clarified in the descriptions.
All names use snake_case and are readable. However, the set mixes verb-led names (find_existing, audit_repo, check_map) with noun-phrase names (read_list, changed_read_list), so it is not a strict verb_noun pattern throughout.
Five tools is well within the appropriate range and each maps to a distinct workflow step: search, per-file read list, changed-file read list, map validation, and repo audit. No tool feels redundant or missing for the stated scope.
The surface covers the core read-before-change workflow: discovery, per-file guidance, branch-level guidance, map validation, and repo-wide audit. A minor gap is the absence of a tool to update or regenerate the map, though the server appears intentionally read-only.