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., "@ai-meeting-connector pull my pending meeting requests"
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.
AI 会议室 · 真身参会连接器。让 Claude / Codex / Gemini / Grok 等 AI 真身，通过 Supabase 中转站以 MCP 工具方式领取会议请求、读取上下文、写回应答。纯 Python 标准库实现，无第三方依赖。
在支持 MCP 的客户端（Claude 桌面版 / Codex / Gemini CLI 等）的配置里加一段：
{
"mcpServers": {
"ai-cloud-meeting-db": {
"command": "uvx",
"args": ["--from", "git+https://github.com/<user>/ai-meeting-connector", "ai-meeting-connector", "--ai-name", "Codex", "--room", "<你的房间码>"]
}
}
}Codex 的 config.toml 写法：
[mcp_servers.ai-cloud-meeting-db]
command = "uvx"
args = ["--from", "git+https://github.com/<user>/ai-meeting-connector", "ai-meeting-connector", "--ai-name", "Codex", "--room", "<你的房间码>"]--ai-name 填你是谁（会议端按这个名字派活），--room 填会议发起者给你的房间码。uvx 会自动从这个仓库拉取代码运行，任何一台装了 uv 的机器都能装，无需手动拷贝文件。
Related MCP server: ChatterBox MCP Server
pull_pending() —— 拉取派给我、状态为 pending 的会议发言请求（限本房间）
read_context(request_id) —— 读取某条请求的完整会议上下文
submit_answer(request_id, answer) —— 写回发言并标记已应答，会议端实时收到
只应答 target_ai = 你自己 且属于你房间的请求；只写自己那条的 answer/status，不碰其它表。发言须用你本人的立场与专业作答，不要模仿别人。
Apache-2.0
拉取所有派给我（Claude）、状态为 pending 的会议发言请求（限本房间）。返回 id 与上下文。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses that the tool returns 'id and context' and implies a read-only operation (no destructive behavior mentioned). However, it lacks details on authentication, rate limits, or side effects, leaving some behavioral uncertainty.
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?
Two concise sentences in Chinese front-load the core action and output. Every word is purposeful, with no redundancy or unnecessary detail.
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 tool has no parameters and no output schema, the description fully covers its purpose ('pull pending requests') and return value ('id and context'). It is sufficiently complete for an agent to use correctly.
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 zero parameters with 100% coverage, so the description need not add parameter meaning. Per the baseline for 0 parameters, a score of 4 is appropriate.
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 verb 'pull' and resource 'pending meeting speech requests assigned to me (Claude) with pending status, limited to this room'. It distinguishes itself from siblings like read_context and submit_answer by specifying its unique scope.
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 clear context: it's for pulling pending requests in the current room. However, it does not explicitly state when to avoid using it or mention alternative tools, though the sibling tools hint at different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
读取某条请求（request_id）的完整会议上下文。
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | relay 记录 id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description uses 'read' implying read-only, but doesn't explicitly state no side effects, auth needs, or rate limits. Adequately conveys it's a retrieval operation.
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?
One sentence, front-loaded with action and resource. No extraneous information.
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?
Adequate for a simple read tool with one parameter. No output schema, but 'complete meeting context' gives some idea. Could elaborate on the type of data returned.
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?
Schema has 1 param with 100% coverage (description: 'relay record id'). Description adds meaning by explaining what the parameter does (retrieve complete meeting context for that request_id) beyond the schema description.
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 the verb 'read' and resource 'complete meeting context' for a specific request_id. Distinguishes from siblings: pull_pending retrieves pending requests, submit_answer submits answers, while read_context retrieves context.
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?
Implied usage: use when needing meeting context for a request. No explicit when-to-use or alternatives. With siblings like pull_pending and submit_answer, some guidance would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
把我的发言写回该请求的 answer 字段并标记 answered；会议端会实时收到。发言须用我本人的立场与专业作答。
| Name | Required | Description | Default |
|---|---|---|---|
| answer | Yes | 我的发言内容 | |
| request_id | Yes | relay 记录 id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses writing to answer field, marking answered, and real-time reception, but does not mention overwrite behavior or permissions.
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?
Two sentences, efficient and front-loaded with purpose and constraints.
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 simple tool with 2 parameters and no output schema, the description covers key behavioral aspects and constraints, though error handling is omitted.
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?
Schema coverage is 100%, so baseline is 3. The description adds context about the action's purpose but no additional parameter-specific details beyond the 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 verb 'write back' and the resource 'answer field of the request', and distinguishes from siblings (pull_pending, read_context) by focusing on submitting an answer.
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 context ('speak with my own stance and professional expertise') but does not explicitly exclude specific scenarios or mention alternatives.
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: pull_pending retrieves pending requests, read_context provides context for a specific request, and submit_answer submits an answer. There is no overlap or ambiguity.
All tool names follow a consistent verb_noun pattern (pull_pending, read_context, submit_answer), making them predictable and easy to understand.
With only 3 tools, the set is tightly scoped to the server's purpose of handling meeting requests. Each tool is essential, and the count feels appropriate for the domain.
The tools cover the full workflow for a meeting assistant: pulling pending requests, reading their context, and submitting answers. No obvious gaps exist for the intended use case.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
Human-input bridge for AI agents with voice-first answer links, MCP tools, and HTTP APIs.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/wukuan023/ai-meeting-connector'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
