Steady MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| STEADY_EMAIL | No | Your Steady account email address | |
| STEADY_BASE_URL | No | The base URL for the Steady web app | https://app.steady.space |
| STEADY_PASSWORD | No | Your Steady account password (plaintext - not recommended for production) | |
| STEADY_MCP_DEBUG | No | Enable debug output (warning: may include sensitive cookies). Set to '1' to enable. | 0 |
| STEADY_COOKIES_PATH | No | Override path for cookies.txt file | |
| STEADY_COOKIE_JAR_PATH | No | Override path for cookiejar.txt file (curl jar format) | |
| STEADY_KEYCHAIN_ACCOUNT | No | macOS Keychain account name for password lookup (typically your email) | |
| STEADY_KEYCHAIN_SERVICE | No | macOS Keychain service name for password lookup | steady-mcp |
| STEADY_PASSWORD_COMMAND | No | Command that prints the password to stdout (no prompts). Recommended over plaintext password. |
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
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| steady_loginA | Log into Steady using the email+password flow and store fresh cookies locally for other tools to use. Reads credentials from env vars (STEADY_EMAIL + STEADY_PASSWORD or STEADY_PASSWORD_COMMAND or macOS Keychain). |
| steady_set_cookiesA | Store Steady cookies (Cookie header value) locally so other tools can authenticate. Provide at least remember_user_token and/or _sthr_session. |
| steady_pingB | Verify the stored cookies can access Steady (checks /check-ins). |
| steady_list_teamsA | List available teams (name + id) from the check-in edit page for a date (default: today). |
| steady_submit_checkinB | Submit today's Steady check-in for ONE team (no official API; uses Steady's web form). Supports: previous work, next work, blockers, and mood. |
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
Each tool has a clearly distinct purpose with no overlap: steady_login handles authentication, steady_ping verifies session validity, steady_set_cookies stores authentication data, steady_list_teams retrieves team information, and steady_submit_checkin submits check-in data. The descriptions make it unambiguous which tool to use for each task.
All tools follow a perfect consistent naming pattern: 'steady_' prefix followed by a verb_noun combination (e.g., steady_login, steady_list_teams, steady_submit_checkin). This provides excellent predictability and readability across the entire toolset.
With 5 tools, this is well-scoped for a Steady check-in automation server. Each tool earns its place by covering essential authentication, verification, data retrieval, and submission functions without being overly sparse or bloated.
The toolset covers the core workflow for Steady check-ins: authentication (login/set_cookies), verification (ping), team selection (list_teams), and submission (submit_checkin). A minor gap exists in not providing tools for viewing past check-ins or managing multiple teams in batch operations, but agents can work effectively with the provided coverage.