Integrates with Google OAuth for authentication to access the YST KPI system for automated daily report collection
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@YST KPI Daily Report Collector collect reports from July to September 2025"
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.
基于 FastMCP 开发的日报数据自动采集工具，支持从 KPI 系统批量采集指定月份范围的日报数据，并自动生成 Markdown 格式报告。
✅ 自动登录：使用 Playwright 自动打开浏览器，完成 Google OAuth 登录
✅ 持久化会话：登录一次长期有效，会话数据自动保存
✅ 批量采集：支持一次性采集多个月份的日报数据
✅ 智能检测：自动识别登录状态，7秒检测间隔，不卡顿
✅ 格式化输出：自动生成结构化 Markdown 报告
✅ 灵活配置：支持自定义输出路径和采集范围
Related MCP server: Instagram MCP Investigator
Python: >= 3.10
包管理器: uv
浏览器: Chromium（Playwright 自动安装）
网络: 能访问 https://kpi.drojian.dev
cd /Users/admin/go/empty/python/yst_mcp
# 使用 uv 同步依赖
uv sync
# 激活虚拟环境
source .venv/bin/activate
# 安装 Playwright 浏览器
playwright install chromium编辑 Claude Desktop 的 MCP 配置文件：
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
添加以下配置：
{
"mcpServers": {
"yst-mcp": {
"command": "uv",
"args": [
"--directory",
"/Users/admin/go/empty/python/yst_mcp",
"run",
"fastmcp",
"run",
"server.py"
]
}
}
}注意：请将路径 /Users/admin/go/empty/python/yst_mcp 修改为你的实际项目路径。
保存后，重启 Claude Desktop 即可生效。
在 Claude Desktop 中直接对话：
使用 yst_mcp 采集 2025-07 到 2025-09 的日报首次使用会自动打开浏览器，完成 Google 登录后，系统会自动：
提取并保存 Cookie
保存浏览器会话
采集指定月份的日报
生成 Markdown 文件
工具名称 | 功能说明 | 是否必需 |
| 采集日报（自动登录） | 核心工具 |
| 手动打开浏览器登录 | 可选 |
| 检查登录状态 | 辅助工具 |
| 清除登录信息 | 辅助工具 |
| 手动保存 Cookie（已弃用） | 已弃用 |
使用 yst_mcp 采集 2025-04 到 2025-06 的日报用 yst_mcp 采集 2025-07 月的日报，保存到 /Users/admin/Downloads/july.md使用 yst_mcp 检查登录状态使用 yst_mcp 清除 Cookie项目提供了 test_login.py 测试脚本，用于调试登录功能：
# 激活虚拟环境
source .venv/bin/activate
# 运行测试脚本
python test_login.py测试脚本会：
启动浏览器
打开登录页面
等待你完成登录
检测登录状态
保存 Cookie 和会话
# 使用 FastMCP 开发模式（带热重载）
uv run fastmcp dev server.py
# 或者生产模式
uv run fastmcp run server.py# 创建测试文件 test_collect.py
import asyncio
from report_collector import ReportCollector
async def test():
collector = ReportCollector()
result = await collector.collect("2025-07", "2025-09", "output.md")
print(result)
asyncio.run(test())采集指定月份范围的日报数据。
参数：
start_month (必需): 起始月份，格式 YYYY-MM，如 2025-07
end_month (必需): 结束月份，格式 YYYY-MM，如 2025-09
output_file (可选): 输出文件路径，默认 data/new.md
auto_login (可选): 是否自动登录，默认 true
返回：采集结果描述（成功/失败信息）
示例：
采集 2025-07 到 2025-09 的日报，保存到 /Users/admin/Downloads/reports.md手动打开浏览器进行登录（一般不需要，collect_reports 会自动调用）。
参数：
use_persistent (可选): 是否使用持久化浏览器，默认 true
timeout (可选): 登录超时时间（秒），默认 300
返回：登录结果
检查当前登录状态，确认 Cookie 是否有效。
参数：无
返回：
✓ 已登录，Cookie 有效 - 可以正常采集
❌ Cookie 已过期 - 需要重新登录
❌ 未找到保存的 Cookie - 首次使用，需要登录
清除保存的登录信息（Cookie 和浏览器会话）。
参数：无
返回：清除结果
注意：清除后需要重新登录！同时会删除：
data/cookies.json
data/browser_profile/ 目录（19MB 浏览器会话数据）
手动保存浏览器 Cookie 字符串。
推荐：直接使用 collect_reports 或 browser_login，无需手动保存 Cookie。
python/yst_mcp/
├── server.py # MCP 服务主入口（5 个工具）
├── browser_login.py # 浏览器自动登录模块
├── cookie_manager.py # Cookie 持久化管理
├── report_collector.py # 日报采集核心逻辑
├── test_login.py # 登录测试脚本
├── pyproject.toml # uv 项目配置
├── README.md # 使用说明（本文件）
├── .venv/ # 虚拟环境
└── data/
├── cookies.json # Cookie 存储文件（8KB）
├── browser_profile/ # 浏览器持久化会话（19MB）
└── new.md # 默认输出文件graph LR
A[检查登录状态] --> B{Cookie有效?}
B -->|是| F[采集数据]
B -->|否| C[启动浏览器]
C --> D[Google OAuth 登录]
D --> E[保存Cookie和会话]
E --> F详细步骤：
检查 data/cookies.json 和 data/browser_profile/ 是否存在
如果不存在，启动 Playwright 浏览器
打开 https://kpi.drojian.dev/report/report-daily/my-list
等待用户完成 Google OAuth 登录
每 7 秒检测一次登录状态：
URL 包含 kpi.drojian.dev → 已登录
URL 包含 my-list → 登录成功
提取 Cookie 并保存到 data/cookies.json
浏览器会话保存到 data/browser_profile/
遍历月份 → 访问页面 → 解析HTML → 提取数据 → 生成Markdown详细步骤：
遍历起始月份到结束月份（如 2025-07 到 2025-09）
对每个月份，访问：
https://kpi.drojian.dev/report/report-daily/my-list?month=YYYY-MM使用 requests + Cookie 获取页面内容
使用 BeautifulSoup 解析 HTML，提取 #report_list li 元素
提取日报信息：
标题（包含日期、时间、早/晚报标记）
内容（今日计划、今日完成等）
按月份组织数据，生成 Markdown 文件
# YST 日报整理
生成时间：2025-10-05 10:43:48
## 2025-07 月份日报 (22 条)
### 1. 2025-07-30早报:09:41weather（#郑潇）
当前任务：线上服务开发和测试
今日计划:
1. weather配合继续测试
2. 冷备份数据继续处理
...
---
### 2. 2025-07-29早报:09:12weather（#郑潇）
...⚠️ Cookie 安全：data/cookies.json 包含登录凭证，请勿分享或提交到 Git
⚠️ 会话数据：data/browser_profile/ 包含完整浏览器会话，请勿分享
✅ 建议：在 .gitignore 中添加：
data/cookies.json
data/browser_profile/检测间隔：登录检测间隔为 7 秒，避免频繁检查
超时时间：登录超时时间为 5 分钟（300 秒）
持久化会话：首次登录后，浏览器会话自动保存，下次无需重复登录
网络依赖：需要稳定的网络连接访问 kpi.drojian.dev
页面结构：依赖页面 HTML 结构（#report_list），如有变化需调整解析逻辑
浏览器依赖：需要 Chromium 浏览器（Playwright 自动管理）
现象：已经登录了，但检测还在等待
原因：登录后停留在其他页面（如 /work/app/index），未跳转到日报页面
解决：最新版本已修复，会自动检测登录状态并跳转到日报页面
解决方法：
# 方法 1：使用 MCP 工具
使用 yst_mcp 清除 Cookie
使用 yst_mcp 采集 2025-07 到 2025-09 的日报 # 会自动重新登录
# 方法 2：手动清理
rm -rf data/cookies.json data/browser_profile/错误信息：Executable doesn't exist at .../chromium-1187/...
解决方法：
# 安装 Playwright 浏览器
source .venv/bin/activate
playwright install chromium错误信息：net::ERR_CONNECTION_RESET
解决方法：
检查网络连接
确认能访问 https://kpi.drojian.dev
最新版本已添加错误处理，会自动重试
# 清除所有登录数据（Cookie + 浏览器会话）
rm -rf data/cookies.json
rm -rf data/browser_profile/注意：
clear_saved_cookies 只清除 cookies.json
浏览器会话保存在 browser_profile/（19MB）
完全清除需要删除两者
可以，但需要分多次调用。例如：
采集 2025-01 到 2025-03 的日报，保存到 q1.md
采集 2025-04 到 2025-06 的日报，保存到 q2.md可以！支持绝对路径和相对路径：
# 绝对路径
保存到 /Users/admin/Downloads/report.md
# 相对路径（相对于项目目录）
保存到 reports/2025-07.md项目类型: MCP 服务
开发框架: FastMCP
Python 版本: >= 3.10
包管理: uv
浏览器自动化: Playwright (async API)
HTTP 请求: requests + BeautifulSoup4
数据格式: Markdown
✅ 使用 Playwright 实现自动登录
✅ 持久化浏览器会话
✅ 优化登录检测逻辑（7秒间隔）
✅ 自动识别已登录状态并跳转
✅ 添加错误处理和重试机制
✅ 基础日报采集功能
✅ Cookie 持久化存储
✅ Markdown 格式输出
如遇问题，请检查：
✅ Python 版本 >= 3.10
✅ 已执行 uv sync 安装依赖
✅ 已执行 playwright install chromium
✅ 网络能访问 https://kpi.drojian.dev
✅ MCP 配置路径正确
更多问题请查看常见问题部分。
启动浏览器进行登录
✅ 推荐使用流程：
调用此工具启动浏览器
在浏览器中完成 Google 登录（约1分钟）
登录成功后，调用 collect_reports 采集数据
工作流程：
打开浏览器窗口
等待您完成 Google OAuth 登录
自动提取并保存 Cookie
保存浏览器会话
Args: use_persistent: 是否使用持久化浏览器上下文（推荐，默认 True） timeout: 登录超时时间（秒），默认 300 秒（5 分钟）
Returns: 登录结果
| Name | Required | Description | Default |
|---|---|---|---|
| use_persistent | No | ||
| timeout | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes interactive nature (user must complete OAuth), timeout, and automatic cookie/session saving. Since no annotations exist, the description carries full burden and does so adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with header, recommended flow, workflow steps, and args. Some redundancy (e.g., workflow repeats steps), but overall clear and not excessively long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the core process but lacks details on return value format, error conditions, and behavior when login fails. An output schema exists but is not described here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning to both parameters: use_persistent is recommended, timeout unit is seconds with default 300. Schema lacks property descriptions, so description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states launching a browser for login, with explicit steps (open browser, wait for OAuth, save cookies) that distinguish it from sibling tools like check_login_status or clear_saved_cookies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a recommended workflow (call this tool first, then login, then collect_reports), but does not explicitly exclude alternatives or explain when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
检查当前登录状态（建议第一步调用）
✅ 推荐工作流程：
首先调用此工具检查登录状态
如果返回"未登录"，则调用 browser_login 进行登录
登录成功后，调用 collect_reports 采集数据
Returns: 登录状态信息： - "✓ 已登录，Cookie 有效" -> 可以直接采集数据 - "❌ Cookie 已过期" -> 需要调用 browser_login 重新登录 - "❌ 未找到保存的 Cookie" -> 需要调用 browser_login 首次登录
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully carries the burden. It describes the read-only nature of checking status and the possible outcomes, with no destructive hints or contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points and clear sections. Every sentence is meaningful and efficient, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully complete for a parameterless tool. Explains purpose, usage, outputs, and integrates with sibling tools in a recommended flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the baseline is 4. The description adds value beyond schema by explaining return values and workflow. Score 5 for excellent context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks current login status and recommends it as the first step. It differentiates from sibling tools like browser_login and collect_reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit recommended workflow: call this first, then browser_login if not logged in, then collect_reports. Explains return values and next steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
检查 Playwright 浏览器驱动安装状态
Returns: 安装状态信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives minimal behavioral insight beyond 'returns status info'. It doesn't disclose what exactly is checked or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two lines, no unnecessary words. Every part is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description is sufficient. It explains the purpose and return type, though more detail on output structure could be given.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0), so the baseline is 4. The description adds no parameter info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks Playwright browser driver installation status, using a specific verb and resource. It is distinct from sibling tools like browser_login or check_login_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or when not to use. Usage is implied (before browser operations), but no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
清除已保存的 Cookie
Returns: 清除结果
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only states the return value as 'clear result' without detailing what exactly is cleared (e.g., domain-specific, all cookies) or side effects. For a zero-annotation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief at two lines, but lacks structure (no sections, formatting) and is minimally informative. While not verbose, it sacrifices usefulness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-parameter tool with an output schema, the description should at least clarify the nature of 'clear result' (e.g., success/error content, count of cleared cookies). Without annotations, the description leaves significant gaps in understanding the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters, so 100% coverage. Baseline for 0 parameters is 4. Description does not add parameter info, but schema already covers completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The name and description clearly state the action 'clear' and resource 'saved cookies'. It distinguishes from siblings like save_cookies_from_browser (opposite) and browser_login (different operation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like clearing cookies via a login flow or using other cookie management tools. The description implies a simple clearing action but provides no context-appropriate or exclusionary information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
采集指定月份范围的日报数据
⚠️ 重要：使用前请先确保已登录！
推荐流程：
先调用 check_login_status 检查登录状态
如果未登录，调用 browser_login 进行登录
登录成功后，再调用本工具采集数据
这样可以避免采集过程被登录流程阻塞。
Args: start_month: 起始月份，格式 YYYY-MM (例如: 2025-07) end_month: 结束月份，格式 YYYY-MM (例如: 2025-09) output_file: 输出文件路径（可选，默认为 ~/.yst_mcp/output/new.md 或项目目录下 data/new.md） auto_login: 未登录时是否自动启动浏览器登录（默认 False，不推荐设为 True）
Returns: 采集结果描述
| Name | Required | Description | Default |
|---|---|---|---|
| start_month | Yes | ||
| end_month | Yes | ||
| output_file | No | ||
| auto_login | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It warns about potential blocking due to login requirements and states auto_login is not recommended, but lacks details on error handling, data source, or post-collection actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear header, warning, recommended workflow, and parameter list. It is slightly verbose but every sentence adds value, making it appropriately concise for the information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema existence (though vague), the description covers prerequisites, parameter details, and usage workflow. It could elaborate on the return value format or collection behavior, but overall it is sufficient for a data collection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains all parameters: date formats, output file default path options, and the auto_login flag's default and advisory against enabling.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool collects daily report data for a specified month range, using a specific verb ('采集') and resource ('日报数据'). It is distinct from sibling tools which handle login or system checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends a workflow: first check login status, then login if needed, then collect. It warns against setting auto_login to True and provides clear alternatives via sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
保存浏览器 Cookie（用于首次登录）
使用方法：
使用 chrome_devtools_mcp 登录 https://kpi.drojian.dev
登录成功后，从浏览器复制 Cookie 字符串
调用此工具保存 Cookie
Args: cookie_string: Cookie 字符串，格式如 "name1=value1; name2=value2" 或者完整的 curl 命令中的 -b 参数内容
Returns: 保存结果
| Name | Required | Description | Default |
|---|---|---|---|
| cookie_string | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It mentions saving cookies and the expected input format, but does not disclose side effects (e.g., overwriting existing cookies), validation behavior, or error handling. Basic transparency but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for usage, args, and returns. It is front-loaded with the purpose. While not extremely concise, all sentences are informative and no waste is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits details like behavior on repeated calls, success/failure responses, and integration with sibling tools. Given the presence of a return value, more detail on the output would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description fully compensates by specifying the expected format ("name1=value1; name2=value2" or curl -b argument). This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves browser cookies for first login, distinguishing it from sibling tools like browser_login, check_login_status, and clear_saved_cookies. It specifies the resource (cookies) and action (save).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a step-by-step usage guide, explaining when to use the tool (after manual login via chrome_devtools_mcp and copying cookie string). It does not explicitly exclude other scenarios, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: login management (browser_login, check_login_status, clear_saved_cookies, save_cookies_from_browser), installation check (check_playwright_installation), and data collection (collect_reports). No two tools overlap in functionality.
All tools follow a consistent snake_case naming pattern with descriptive verbs (browser_login, check_login_status, check_playwright_installation, clear_saved_cookies, collect_reports, save_cookies_from_browser). The convention is uniform across all tools.
With 6 tools, the server is well-scoped for its purpose of collecting KPI daily reports. Each tool adds necessary functionality without bloat. The number is within the ideal range (3-15) and feels neither too heavy nor too thin.
The tool surface covers the core workflow: login, status checking, cookie management, installation verification, and report collection. A minor gap is the lack of an explicit logout tool, but clear_saved_cookies can partially serve. Overall, the essential operations are present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
Run multi-step tasks in a real Chrome browser: persistent environments, live view, human takeover.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Xuzan9396/yst_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
