How do I use Steady MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Steady MCP submit my check-in for the engineering team: previous - finished API docs, next - review PRs, blockers - none" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Steady MCP

by Sarthak-ignite

Overview Schema Related Servers Score Discussions

JavaScript

Local

Steady MCP (local)

This is a local MCP server that submits Steady check-ins by driving Steady’s web form (there is no official Steady API).

It’s built for the workflow:

You tell the AI: team + check-in fields (previous / next / blockers) → AI calls the MCP tool → Steady check-in is submitted.

What this supports

Email + password login (two-step flow from /signin) via steady_login
Cookie-based auth via steady_set_cookies (fallback for non-standard auth flows)
Team discovery via steady_list_teams
Submitting a check-in for one team via steady_submit_checkin

How it works (important)

Steady rotates the _sthr_session cookie when you load the daily edit page (/check-ins/YYYY-MM-DD/edit).
So this server uses a curl cookie jar (cookiejar.txt) to preserve the updated session cookie between the GET and POST.

Related MCP server: Timesheet MCP Server

Requirements

Node.js 18+
Cursor (or another MCP client) with support for running local MCP servers over stdio
Access to Steady web app (https://app.steady.space)

Install

cd tools/steady-mcp
npm install

Configure Cursor (MCP)

Add a server entry to your Cursor MCP config.

Where is `mcp.json`?

Common locations:

macOS / Linux: ~/.cursor/mcp.json
Windows: %USERPROFILE%\\.cursor\\mcp.json

If you don’t see it, use Cursor’s UI settings for MCP servers (recommended), or search for mcp.json on your machine.

Quickstart: macOS (recommended)

Install Node.js 18+

If you use Homebrew:

brew install node
node -v

Install dependencies

cd <ABS_PATH_TO_REPO>/tools/steady-mcp
npm install

Add steady-mcp to ~/.cursor/mcp.json (example below)
Restart Cursor (quit + reopen)
In Cursor, run:

steady_login
steady_submit_checkin

Quickstart: Windows

Install Node.js 18+

If you use winget:

winget install OpenJS.NodeJS.LTS
node -v

Install dependencies

cd <ABS_PATH_TO_REPO>\tools\steady-mcp
npm install

Add steady-mcp to %USERPROFILE%\.cursor\mcp.json
Restart Cursor (fully quit + reopen)
In Cursor, run:

steady_login
steady_submit_checkin

Example `mcp.json` snippet

Replace <ABS_PATH_TO_REPO> and your email.

{
  "mcpServers": {
    "steady-mcp": {
      "command": "node",
      "args": [
        "<ABS_PATH_TO_REPO>/tools/steady-mcp/src/index.js"
      ],
      "env": {
        "STEADY_BASE_URL": "https://app.steady.space",
        "STEADY_EMAIL": "you@company.com",
        "STEADY_PASSWORD": "<YOUR_PASSWORD>",
        "STEADY_MCP_DEBUG": "0"
      }
    }
  }
}

Windows path tip (important)

In JSON, Windows backslashes require escaping. Easiest option: use forward slashes in the args path:

{
  "mcpServers": {
    "steady-mcp": {
      "command": "node",
      "args": [
        "C:/Users/<YOU>/path/to/repo/tools/steady-mcp/src/index.js"
      ],
      "env": {
        "STEADY_BASE_URL": "https://app.steady.space",
        "STEADY_EMAIL": "you@company.com",
        "STEADY_PASSWORD": "<YOUR_PASSWORD>"
      }
    }
  }
}

Security note

STEADY_PASSWORD in mcp.json is the simplest setup, but it’s not ideal for security.
Prefer STEADY_PASSWORD_COMMAND (password retrieved at runtime) whenever possible.

Credentials / Secrets (cross-platform)

The server reads credentials from environment variables provided by your MCP client.

Option A (simple): plaintext env password

STEADY_EMAIL
STEADY_PASSWORD

Option B (recommended): password command

STEADY_EMAIL
STEADY_PASSWORD_COMMAND — command that prints the password to stdout (no prompts)

Examples:

macOS Keychain (recommended on macOS)
1. Store once:

security add-generic-password -a "you@company.com" -s "steady-mcp" -w "<YOUR_PASSWORD>" -U

In MCP env:
- STEADY_PASSWORD_COMMAND=security find-generic-password -w -s steady-mcp -a you@company.com

Windows: use a password manager CLI (e.g. 1Password CLI / Bitwarden CLI) or a small local script that prints the password.
Any OS: use your password manager’s CLI, or a small script you keep outside git.

Option C (macOS-only fallback): Keychain lookup without a command

If you have a Keychain entry, the server can read it automatically on macOS:

STEADY_EMAIL=you@company.com
optionally STEADY_KEYCHAIN_SERVICE=steady-mcp
optionally STEADY_KEYCHAIN_ACCOUNT=you@company.com

Authentication options

Use:

steady_login

This will log in and write:

cookies.txt (Cookie header string)
cookiejar.txt (curl jar; used internally to handle session rotation)

If login automation doesn’t work for your Steady account, you can set cookies from your browser:

In Steady (browser): DevTools → Application/Storage → Cookies → https://app.steady.space
Copy these cookies:
- _sthr_session
- remember_user_token (if present)
Build a Cookie header string:

_sthr_session=...; remember_user_token=...

Call:

steady_set_cookies with { "cookies": "_sthr_session=...; remember_user_token=..." }

File locations (where cookies are stored)

Defaults (can be overridden via env):

macOS
- cookies: ~/Library/Application Support/steady-mcp/cookies.txt
- jar: ~/Library/Application Support/steady-mcp/cookiejar.txt
Windows
- cookies: %APPDATA%\\steady-mcp\\cookies.txt
- jar: %APPDATA%\\steady-mcp\\cookiejar.txt
Linux
- cookies: $XDG_CONFIG_HOME/steady-mcp/cookies.txt (or ~/.config/steady-mcp/cookies.txt)
- jar: $XDG_CONFIG_HOME/steady-mcp/cookiejar.txt (or ~/.config/steady-mcp/cookiejar.txt)

Overrides:

STEADY_COOKIES_PATH
STEADY_COOKIE_JAR_PATH

Usage (day-to-day)

Step 0: Restart Cursor

After adding/updating MCP config, fully restart Cursor (quit + reopen).

Call:

steady_login

Then verify:

steady_ping → should return { "ok": true }

Step 2: List team names (optional)

Call:

steady_list_teams

Step 3: Submit today’s check-in for one team

Call:

steady_submit_checkin

Example:

{
  "team": "Everest AI",
  "previous": "Wrapped up CI fixes and reviewed PRs.",
  "text": "Next: finalize the MCP schema changes and update docs.",
  "blockers": "No blockers.",
  "mood": "calm"
}

Success is typically:

status_code: 302

Tools (API surface)

steady_login: log in and save cookies locally
steady_set_cookies: save browser cookies manually
steady_ping: validate auth
steady_list_teams: list team names/ids from the daily edit page
steady_submit_checkin: submit for one team

Troubleshooting

Start here: docs/TROUBLESHOOTING.md

Common issues:

Tool not found in Cursor
- fully restart Cursor
- verify the mcp.json entry path is correct and absolute
- verify npm install was run in tools/steady-mcp
HTTP 422
- usually means the submission was rejected (already checked in / stale session / insufficient permission)
- run steady_login again and retry
- confirm the team is actually pending on Steady’s daily page
Need debug
- set STEADY_MCP_DEBUG=1 (warning: debug output may include sensitive cookies)

Available Tools

5 tools

steady_list_teamsA

List available teams (name + id) from the check-in edit page for a date (default: today).

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	YYYY-MM-DD (optional; default: today)

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that the tool lists teams with name and id from a specific page, which is useful context. However, it lacks details on behavioral traits like permissions needed, rate limits, or error handling, leaving gaps in transparency for a tool that likely interacts with a system.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the purpose and includes key details like the source and default behavior. There is no wasted text, making it appropriately sized and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (1 optional parameter, no output schema, no annotations), the description is adequate but minimal. It covers the purpose and basic usage but lacks details on output format or error scenarios, which could be helpful for an agent invoking the tool without an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the 'date' parameter fully. The description adds minimal value by mentioning 'default: today', which is already in the schema description. No additional semantics beyond the schema are provided, meeting the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('List available teams') and the resource ('teams (name + id)'), with additional context about the source ('from the check-in edit page for a date'). It distinguishes from siblings like steady_login or steady_submit_checkin by focusing on listing rather than authentication or submission.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for usage ('from the check-in edit page for a date'), including a default behavior ('default: today'), which helps guide when to use it. However, it does not explicitly state when not to use it or name alternatives among siblings, such as steady_ping for health checks.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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).

ParametersJSON Schema

Name	Required	Description	Default
`email`	No	Optional override for STEADY_EMAIL.

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses that the tool performs authentication ('Log into Steady'), stores cookies locally, and reads credentials from multiple sources. However, it doesn't mention potential side effects (e.g., invalidating previous sessions), error behaviors, or rate limits. The description adds useful context but lacks comprehensive behavioral details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured in two sentences: the first states the core purpose and outcome, the second explains credential sources. Every phrase adds value without redundancy, and it's appropriately front-loaded with the main functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's authentication purpose with no annotations and no output schema, the description does well by explaining the login flow, cookie storage, and credential sources. However, it doesn't describe what happens on success/failure or return values, which would be helpful for a mutation tool. The coverage is good but not fully comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% description coverage for its single parameter, documenting that 'email' is an optional override. The description adds meaningful context by explaining the default credential sources (STEADY_EMAIL env var, etc.), which helps the agent understand parameter usage beyond the schema's technical specification. For a single parameter tool, this provides good supplemental information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Log into Steady'), the mechanism ('using the email+password flow'), and the outcome ('store fresh cookies locally for other tools to use'). It distinguishes itself from siblings like steady_ping or steady_list_teams by focusing on authentication rather than data retrieval or status checking.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context about when to use this tool ('for other tools to use') and mentions credential sources (env vars, macOS Keychain), but doesn't explicitly state when NOT to use it or name alternatives like steady_set_cookies for cookie management. The guidance is practical but lacks explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

steady_pingB

Verify the stored cookies can access Steady (checks /check-ins).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states the tool verifies access via cookies and checks the /check-ins endpoint, but doesn't disclose behavioral traits like what happens on success/failure, whether it's read-only or has side effects, error conditions, or rate limits. The description is minimal and lacks operational context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, with zero waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is adequate but minimal. It covers the basic purpose but lacks details on behavior, usage context, or output format, which could be helpful for an agent to understand how to interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter details beyond the schema, but that's appropriate here. Baseline is 4 for zero parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Verify the stored cookies can access Steady (checks /check-ins).' It specifies the verb ('verify'), resource ('stored cookies'), and target system ('Steady'), though it doesn't explicitly differentiate from sibling tools like steady_login or steady_set_cookies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The description implies it's for verifying cookie-based access to Steady, but doesn't specify prerequisites (e.g., cookies must be set first) or when to choose this over steady_login for authentication checks.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema

Name	Required	Description	Default
`cookies`	Yes	Cookie header value, e.g. `_sthr_session=...; remember_user_token=...`

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses that this stores cookies locally for authentication purposes, which implies persistence and sharing across tools. However, it doesn't mention security implications, storage duration, or whether this overwrites existing cookies. The behavioral context is adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly concise with two sentences that each earn their place: the first states the core purpose and benefit, the second specifies requirements. There's zero waste or redundancy, and information is front-loaded appropriately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (authentication storage with 1 parameter), no annotations, and no output schema, the description is reasonably complete. It covers purpose, usage context, and parameter requirements. However, it could better address behavioral aspects like security or persistence details to be fully comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already fully documents the single parameter. The description adds minimal value beyond the schema by emphasizing the required cookie types, but doesn't provide additional syntax, format, or validation details. This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Store Steady cookies locally') and the resource ('Cookie header value'), distinguishing it from sibling tools like steady_login (which likely obtains cookies) and steady_list_teams (which uses them). It explicitly mentions the purpose of enabling authentication for other tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context about when to use this tool: to store authentication cookies for other tools. It specifies required cookie types ('at least remember_user_token and/or _sthr_session'), but doesn't explicitly state when NOT to use it or name alternatives (like whether steady_login should be used first).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema

Name	Required	Description
`team`	Yes	Team name or team UUID.
`text`	Yes	What will you do next? (Steady field: next)
`previous`	No	What did you do previously? (optional; Steady field: previous)
`blockers`	No	Are you blocked by anything? (optional; Steady field: blockers)
`mood`	No	Mood (optional). Default: calm.
`date`	No	YYYY-MM-DD (optional; default: today)

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions using Steady's web form (not an official API), which hints at potential reliability or rate limit issues, but doesn't specify authentication requirements, error handling, or what happens on submission (e.g., confirmation, side effects). For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main purpose and efficiently lists supported fields in a single sentence. It avoids redundancy and is appropriately sized for the tool's complexity. However, it could be slightly more structured by separating usage notes from field descriptions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is moderately complete but has gaps. It covers the tool's purpose and parameters well via the schema, but lacks details on behavioral aspects like authentication, error handling, or return values. For a mutation tool with 6 parameters, it should provide more context on how the tool behaves in practice.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds minimal value by listing supported fields (previous work, next work, blockers, mood) but doesn't provide additional context beyond what's in the schema (e.g., format details for 'team' or 'date'). Baseline 3 is appropriate as the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Submit today's Steady check-in') and resource ('for ONE team'), specifying it's for a single team rather than multiple. It distinguishes from siblings by mentioning it uses Steady's web form (not an official API), but doesn't explicitly differentiate from steady_login or steady_set_cookies which might be related to authentication. The purpose is specific but could better contrast with other tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for submitting daily check-ins and mentions it's for one team, but provides no explicit guidance on when to use this tool versus alternatives like steady_list_teams or steady_login. It doesn't state prerequisites (e.g., needing authentication first) or exclusions (e.g., not for historical dates beyond today). Usage is contextually implied but lacks clear directives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

agent-web-actions
com.trycloudflare.plates-spread-materials-optimum
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Browser Automation Agent Orchestration
2
agent-web-actions
com.trycloudflare.clients-involving-billion-headers
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Browser Automation Web Scraping
2
shortcut-mcp
io.github.stayce
Shortcut project management. Create, update, search stories and manage workflows.
Project Management Developer Tools
22
parabol A
io.usefulapi
Start Parabol retrospectives, standups and sprint poker; read teams/meetings/tasks; create tasks.
Project Management Communication
212

Related MCP Servers

YST KPI Daily Report Collector
Browser Automation Web Scraping App Automation
Xuzan9396
F
license
A
quality
C
maintenance
Automatically collects daily report data from KPI systems using browser automation and Google OAuth login. Generates structured Markdown reports for specified date ranges with persistent session management.
Updated a year ago (2025-10-05 14:23 UTC)
6
Timesheet MCP Server
App Automation Workplace & Productivity Project Management
arshad-khan1
A
license
Not graded
quality
D
maintenance
Enables automated timesheet management including creating entries, listing work activities, managing daily scrum updates, and viewing assigned projects with automatic authentication handling.
Updated 9 months ago (2025-12-18 07:17 UTC)
13
MIT
Timesheet Assistant MCP
Browser Automation App Automation Workplace & Productivity
sharadmathuratthepsi
A
license
Not graded
quality
C
maintenance
Generates timesheets from activity data and automates submission to PSI Project Server (SharePoint-based systems) using browser automation. Works with Activity Collector MCP to fetch data from GitLab, GitHub, and Calendar services.
Updated a month ago (2026-07-30 02:55 UTC)
21
MIT
standup-mcp
Version Control Project Management Communication
sathvic-kollu
A
license
A
quality
C
maintenance
Generates daily standup drafts from your actual GitHub, Jira, Linear, and Slack activity, grouping work items and detecting blockers.
Updated 3 months ago (2026-06-17 08:27 UTC)
5
48
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Sarthak-ignite/steady-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Steady MCP (local)

What this supports

How it works (important)

Requirements

Install

Configure Cursor (MCP)

Where is mcp.json?

Quickstart: macOS (recommended)

Quickstart: Windows

Example mcp.json snippet

Windows path tip (important)

Security note

Credentials / Secrets (cross-platform)

Option A (simple): plaintext env password

Option B (recommended): password command

Option C (macOS-only fallback): Keychain lookup without a command

Authentication options

1) Login automation (email → password)

2) Cookie-based auth (fallback)

File locations (where cookies are stored)

Usage (day-to-day)

Step 0: Restart Cursor

Step 1: Login (refresh cookies)

Step 2: List team names (optional)

Step 3: Submit today’s check-in for one team

Tools (API surface)

Troubleshooting

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Where is `mcp.json`?

Example `mcp.json` snippet