ready-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| READY_MODEL | No | The model name to use with the OpenAI-compatible endpoint. | |
| READY_API_KEY | No | API key for the OpenAI-compatible endpoint. Without a key, Ready still works on repo search alone. | |
| READY_BASE_URL | No | The base URL of an OpenAI-compatible endpoint serving an open model. |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_readinessB | Check whether an issue is ready to hand to a coding agent, before starting work on it.
|
| predict_footprintC | Files in the checkout most likely to need editing for this issue text, best first. |
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 2 tools
The two tools have clearly distinct purposes: one evaluates issue readiness and the other predicts likely file edits. Their outputs and workflows are separate enough that an agent should not confuse them.
Both names follow a consistent snake_case verb_noun pattern: check_readiness and predict_footprint. There is no mixed convention or vague naming.
The server has a narrow purpose, but two tools is thin for a useful workflow surface. Each tool earns its place, yet the set feels borderline minimal.
The core operations for issue handoff are covered: readiness checking and footprint prediction. Minor supporting operations could be added, but no major workflow dead end is obvious.