de en es ja ko ru zh

Geekbot MCP

Name: Geekbot MCP
Author: geekbot-com

Official

by geekbot-com

Overview Schema Source Related Servers Discussions(1)Admin

Python

Local

Geekbot MCP

Geekbot MCP 徽标许可证：MIT Python 3.10+ PyPI 版本铁匠徽章

在你的 LLM 申请中解锁你的 Geekbot 数据🚀

Geekbot MCP（模型上下文协议）服务器充当桥梁，将 LLM 客户端应用程序（例如 Claude、Cursor、Windsurf 等）直接连接到您的 Geekbot 工作区。这使您可以使用自然语言在对话中与站立会议、报告和团队成员无缝交互。

主要特点✨

访问站立会议和民意调查信息：列出 Geekbot 工作区中的所有站立会议和民意调查。📊
检索站立会议报告和投票结果：使用特定站立会议、用户或日期范围的过滤器获取报告和投票结果。📄
查看团队成员：获取您在 Geekbot 中合作的成员列表。👥
发布站立报告：向 Geekbot 发布站立报告。📝

Related MCP server: Notion MCP Server

安装💻

通过 Smithery 安装

要通过Smithery安装 Geekbot MCP 作为远程服务器：

npx -y @smithery/cli install @geekbot-com/geekbot-mcp --client claude

远程服务器将随着每次发布自动更新到最新版本。

有关Smithery 数据政策的更多信息

手动安装

需要 Python 3.10+ 和uv 。

安装 Python 3.10+（如果尚未安装）：
- macOS：
  brew install python@3.10
  有关更多详细信息，请参阅Homebrew Python 安装指南。
- Ubuntu/Debian：
  sudo apt update sudo apt install python3.10
- **Windows：**从Python.org下载并安装。
  有关更多详细信息，请参阅Windows Python 安装指南。
安装 uv（如果还没有安装）：
- **macOS/Linux：**在您的终端中，运行以下命令：
  curl -LsSf https://astral.sh/uv/install.sh | sh
- **Windows：**在 PowerShell 中，运行以下命令：
  powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
（更多选项请参阅uv 安装文档。）
安装/升级 Geekbot MCP：
- **macOS/Linux：**在您的终端中，运行以下命令：
  uv tool install --upgrade geekbot-mcp
- **Windows：**在 PowerShell 中，运行以下命令：
  uv tool install --upgrade geekbot-mcp

配置⚙️

安装 Geekbot MCP 后，您可以将其连接到 LLM 客户端桌面应用程序（例如，Claude Desktop、Cursor、Windsurf 等）：

**获取您的 Geekbot API 密钥：**在您的Geekbot API/Webhooks 设置中找到它🔑。
找到您的uv可执行路径：

**Linux/macOS：**在您的终端中，运行以下命令：
```
  which uv
```

**Windows：**在 PowerShell 中，运行以下命令：

  (Get-Command uv | Select-Object -ExpandProperty Path) -replace '\\', '\\'

**配置您的 LLM 客户端桌面应用程序：**每个支持 MCP 的 LLM 客户端都提供一个配置文件，您可以编辑该文件以添加 Geekbot MCP 服务器。

如果您使用不同的 LLM 客户端，请参阅客户端的文档以了解如何配置 MCP 服务器。

找到配置文件后，编辑它以添加 Geekbot MCP 服务器：

    {
      "mcpServers": {
        "geekbot-mcp": {
          "command": "UV-PATH",
          "args": [
            "tool",
            "run",
            "geekbot-mcp"
          ],
          "env": {
            "GB_API_KEY": "YOUR-API-KEY"
          }
        }
      }
    }

确保替换：

UV-PATH为步骤 2 中uv可执行文件的路径
YOUR-API-KEY为您在步骤 1 中得到的 Geekbot API 密钥

使用方法💡

配置完成后，您的 LLM 客户端应用程序将可以访问以下工具并提示与您的 Geekbot 数据进行交互：

工具🛠️

list_standups

**用途：**列出所有可通过 API 密钥访问的站立会议。可用于概览或查找特定的站立会议 ID。

示例提示： “嘿，你能列出我的 Geekbot 站立会议吗？”

返回的数据字段：

id ：唯一站立标识符。
name ：站立会议的名称。
channel ：相关通信渠道（例如，Slack 渠道）。
time ：站立报告的预定时间。
timezone ：预定时间的时区。
questions ：站立会议上提出的问题列表。
participants ：参与站立会议的用户列表。
owner_id ：站立会议所有者的 ID。
confidential ：站立会议是否保密。
anonymous ：站立会议是否匿名。

list_polls

**用途：**列出所有可通过 API 密钥访问的投票。可用于概览或查找特定的投票 ID。

示例提示： “嘿，你能列出我的 Geekbot 民意调查吗？”

返回的数据字段：

id ：唯一轮询标识符。
name ：投票的名称。
time ：投票的预定时间。
timezone ：预定时间的时区。
questions ：民意调查中提出的问题列表。
participants ：参与投票的用户列表。
creator ：投票创建者。

fetch_reports

**用途：**检索特定的站立会议报告。您可以按站立会议、用户和日期范围进行筛选。

示例提示：

“获取昨天提交的回顾报告。”
“显示用户 John Doe 的‘每周同步’站立会议报告。”
“获取 2024 年 6 月 1 日之后提交给每日站立会议的所有报告。”

可用的过滤器：

standup_id ：按特定的站立 ID 进行过滤。
user_id ：按特定用户 ID 过滤报告。
after ：检索此日期 (YYYY-MM-DD) 之后提交的报告🗓️。
before ：检索在此日期之前提交的报告（YYYY-MM-DD）🗓️。

返回的数据字段：

id ：唯一报告标识符。
reporter_name ：提交报告的用户的姓名。
reporter_id ：提交报告的用户的 ID。
standup_id ：报告所属站立会议的 ID。
created_at ：提交报告的时间戳。
content ：报告的实际答案/内容。

post_report

**目的：**向 Geekbot 发布报告。

提示示例： “嘿，你能发布每日站立会议的报告吗？”

返回的数据字段：

id ：唯一报告标识符。
reporter_name ：提交报告的用户的姓名。
reporter_id ：提交报告的用户的 ID。
standup_id ：报告所属站立会议的 ID。
created_at ：提交报告的时间戳。
content ：报告的实际答案/内容。

list_members

**目的：**列出您在 Geekbot 工作区中共享站立会议的所有团队成员。

示例提示： “我的 Geekbot 工作区中有哪些成员？”

返回的数据字段：

id ：唯一会员标识符。
name ：会员的全名。
email ：会员的电子邮件地址。
role ：成员在 Geekbot 中的角色（例如，管理员、成员）。

fetch_poll_results

**目的：**检索特定的投票结果。需要投票 ID 以及可选的日期范围。

示例提示： “嘿，Geekbot 民意调查中关于新徽标的决定是什么？”

返回的数据字段：

total_results ：结果总数。
question_results ：问题结果列表。

提示💬

weekly_rollup_report

**目的：**生成一份全面的每周汇总报告，总结团队站立反应、强调关键更新、识别风险和缓解策略、概述后续步骤并跟踪即将发布的产品。

提示💡

审核工具使用情况：让代理在执行每个工具操作时都请求您的明确批准，并且不允许自动调用工具。此安全功能可确保您控制敏感操作，尤其是在向 Geekbot 发布报告时。系统会在执行每个工具调用之前提示您审核并批准，从而有助于防止意外的数据提交。
请求预览：在发布报告之前，请客服人员预览报告，而不是直接发布。这样，您就有机会在将报告发布到 Geekbot 之前，仔细检查报告，确保其正确无误，或者进行修改。
限制检索的数据量：如果您使用fetch_reports工具，请将日期范围限制在合理的范围内。这有助于防止代理检索大量数据并导致性能问题。请注意，代理会限制其可检索的报告数量。

参数：

standup_id ：要包含在汇总报告中的站立会议的 ID。

开发🧑‍💻

有兴趣贡献或本地运行服务器吗？

设置开发环境

# 1. Clone the repository
git clone https://github.com/geekbot-com/geekbot-mcp.git
cd geekbot-mcp

# 2. Install uv (if needed)
# curl -LsSf https://astral.sh/uv/install.sh | sh

# 3. Create a virtual environment and install dependencies
uv sync

运行测试✅

# Ensure dependencies are installed (uv sync)
pytest

贡献🤝

欢迎贡献代码！请 fork 代码库并提交 Pull 请求，包含你的修改。

许可证📜

该项目已获得MIT 许可。

致谢🙏

建立在人择模型上下文协议框架之上。
利用官方的Geekbot API 。

Available Tools

6 tools

fetch_poll_resultsB

Retrieves Geekbot poll results. Use this tool to analyze poll results or track progress of polls. This tool is usually used after the list_polls tool to get the poll id.

ParametersJSON Schema

Name	Required	Description
`poll_id`	Yes	ID of the specific standup to fetch reports for. If not provided, reports for all standups will be fetched.
`before`	No	Fetch results before this date (format: YYYY-MM-DD). This is not provided unless explicitly asked by the user.
`after`	No	Fetch results after this date (format: YYYY-MM-DD). This is not provided unless explicitly asked by the user.

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must cover behavioral traits. It does not mention whether the operation is read-only, what happens if the poll_id is invalid, or any side effects. This is insufficient for a retrieval tool with no structured behavioral disclosure.

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 two sentences: first clearly states the action, second provides a usage hint. It is front-loaded and contains no unnecessary words.

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

Completeness2/5

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

With no output schema and three parameters, the description is too brief. It does not explain the return format, pagination, error behavior, or what data is included in the results. Agents need more context to use the tool correctly.

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

Parameters2/5

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

The input schema has 100% coverage with descriptions, but the poll_id description says 'ID of the specific standup to fetch reports for', which appears inconsistent with the tool name (polls vs standups). The tool description does not clarify or correct this, so it does not add meaningful value beyond the schema and may even mislead.

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 states 'Retrieves Geekbot poll results' with a specific verb and resource, and also provides use cases (analyze results, track progress). It implies differentiation from siblings like list_polls (which lists polls) by noting it is used after list_polls.

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 mentions it is 'usually used after the list_polls tool to get the poll id', providing a sequential usage hint. However, it does not explicitly compare to alternatives like fetch_reports or state when not to use this tool.

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

fetch_reportsA

Retrieves Geekbot standup reports. Use this tool to analyze team updates or updates from specific colleagues, track progress, or compile summaries of standup activities. This tool is usually used after the list_standups tool.

ParametersJSON Schema

Name	Required	Description
`standup_id`	No	ID of the specific standup to fetch reports for. If not provided, reports for all standups will be fetched.
`user_id`	No	ID of the specific user to fetch reports for. If not provided, reports for all members will be fetched.
`after`	No	Fetch reports after this date (format: YYYY-MM-DD)
`before`	No	Fetch reports before this date (format: YYYY-MM-DD)

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It only states 'Retrieves' without mentioning any potential issues like large result sets if no filters are applied, authentication requirements, or rate limits.

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 very concise with two sentences. The first sentence states the core purpose, and the second provides context on usage and ordering. No unnecessary information.

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 has 4 optional parameters and no output schema, the description adequately covers purpose and usage hint but lacks behavioral details (e.g., default behavior when no filters are set). It is minimally sufficient but not 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?

The input schema has 100% description coverage for all 4 parameters. The description does not add any additional meaning beyond the schema, so it meets the baseline without adding value.

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 tool retrieves Geekbot standup reports, uses specific verbs, and provides use cases like analyzing team updates. It distinguishes from siblings by mentioning it is used after list_standups, differentiating it from fetch_poll_results.

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 explains when to use the tool (to analyze standup reports) and suggests it is typically used after list_standups. However, it does not explicitly state when not to use it or mention alternatives like fetch_poll_results.

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

list_membersA

Lists all team members participating in the standups and polls of the user. Use this tool to get information about the colleagues of the user

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, and the description only implies read-only behavior. It does not disclose permissions, limits, or any side effects, failing to compensate for missing annotations.

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?

Two brief sentences convey the purpose and usage without any unnecessary words. Every sentence adds value.

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?

For a simple list tool with no parameters, the description adequately covers what it returns and its context. Lack of output schema is acceptable for such a straightforward function.

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?

With 0 parameters, the baseline is 4. The description adds no further parameter information, but none is needed.

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 verb ('Lists') and the resource ('team members participating in standups and polls'). It distinguishes from siblings like list_polls and list_standups by focusing on members.

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?

Provides guidance to 'get information about colleagues' but lacks explicit when-not-to-use or alternatives. The sibling tools are different enough that confusion is unlikely.

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

list_pollsA

Retrieves and displays all Geekbot polls a user has access to, including their complete configuration details such as name, time, timezone, questions, participants, recurrence, anonymous, and creator.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

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 bears the full burden. It indicates a read operation ('Retrieves and displays'), but lacks details on side effects, pagination, or error handling. The description is adequate for a simple list but not rich.

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 well-formed sentence that front-loads the purpose and includes key details. Every word earns its place; no unnecessary content.

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 no parameters and no output schema, the description lists the fields returned, which is sufficient for understanding what the tool does. It does not cover error scenarios, but for a simple list tool, it is complete enough.

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 input schema has no parameters (100% coverage vacuously). The description adds meaning by enumerating the configuration fields returned (name, time, timezone, etc.), which is helpful beyond the empty schema. A baseline of 4 is appropriate.

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 verb 'Retrieves and displays' and the resource 'all Geekbot polls a user has access to', with specific fields listed (name, time, etc.). It distinguishes from siblings like fetch_poll_results and list_standups.

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 that this tool is for listing polls, but it does not explicitly state when to use it over alternatives (e.g., fetch_poll_results, list_standups) or any prerequisites (e.g., user authentication). It provides clear context but no exclusions.

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

list_standupsA

Retrieves and displays all Geekbot standups a user has access to, including their complete configuration details such as name, channel, questions, participants, and schedule information. Use this tool to understand the structure of the team and the processes they use track progress and sync.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description must disclose behaviors. It mentions returning configuration details but lacks details on pagination, performance, or limitations. Adequate but not thorough.

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?

Two sentences: first states action and scope, second gives usage guidance. No wasted words.

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 no output schema and no annotations, the description is mostly complete for a zero-param retrieval tool. It could mention pagination or return structure limitations.

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?

Input schema has no parameters, so the description need not add param info. Baseline 4 is appropriate.

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 that it retrieves all Geekbot standups with configuration details, using a specific verb+resource. It distinguishes from siblings like list_members and list_polls.

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 provides a usage context ('understand structure of the team and processes') but does not explicitly compare to alternatives or give when-not-to-use guidance.

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

post_reportA

Posts a report to Geekbot. Use this tool to post a report to Geekbot using the context of the conversation. This tool is usually used after the list_standups tool to get the standup id and the question ids. If the context of the conversation lacks sufficient information to answer the questions of the standup, the assistant will ask for the missing information. The report should be beautifully formatted. ALWAYS type formatted reporte in the conversation for preview purposes before calling this tool.

ParametersJSON Schema

Name	Required	Description	Default
`standup_id`	Yes	ID of the specific standup to post the report to.
`answers`	Yes	An object where keys are the string representation of question IDs and values are objects containing the answer text. All questions of the standup must be included in the object.

TDQS

A4.3/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses the need for preview and handling of missing info, but does not explain success/failure behavior, side effects, or idempotency. Minor typo 'reporte' but not impactful.

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

Conciseness3/5

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

Description is informative but somewhat verbose with slight redundancy (first two sentences say similar things). Could be more concise while retaining key guidance.

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?

Covers workflow (list_standups associations, preview requirement, missing info handling) but lacks explanation of expected output or error conditions. Adequate but could be more complete given no output schema.

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?

Schema has 100% coverage, baseline 3. Description adds value by explaining that standup_id comes from list_standups and that answers must include all question IDs, beyond the schema's description.

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 'Posts a report to Geekbot' and distinguishes from sibling tools (fetch/list operations). It specifies the verb (post) and resource (report), providing unambiguous purpose.

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

Usage Guidelines5/5

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

Explicitly states it is used after `list_standups` to obtain IDs, instructs to ask for missing information, and requires a formatted preview before calling. This provides clear when-to-use and preparatory steps.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesv0.3.4May 6, 2026
- Addedfetch_poll_results
- Changedfetch_reports15 fields changed
  - removedInput schema / properties / after / default
```
Removed value: -null
```
  - addedInput schema / properties / after / description
```
Added value: +"Fetch reports after this date (format: YYYY-MM-DD)"
```
  - removedInput schema / properties / after / title
```
Removed value: -"After"
```
  - removedInput schema / properties / before / default
```
Removed value: -null
```
  - addedInput schema / properties / before / description
```
Added value: +"Fetch reports before this date (format: YYYY-MM-DD)"
```
  - removedInput schema / properties / before / title
```
Removed value: -"Before"
```
  - removedInput schema / properties / standup_id / default
```
Removed value: -null
```
  - addedInput schema / properties / standup_id / description
```
Added value: +"ID of the specific standup to fetch reports for. If not provided, reports for all standups will be fetched."
```
  - removedInput schema / properties / standup_id / title
```
Removed value: -"Standup Id"
```
  - removedInput schema / properties / user_id / default
```
Removed value: -null
```
  - addedInput schema / properties / user_id / description
```
Added value: +"ID of the specific user to fetch reports for. If not provided, reports for all members will be fetched."
```
  - removedInput schema / properties / user_id / title
```
Removed value: -"User Id"
```
  - changedInput schema / properties / user_id / type
```
Previous value: -"integer"New value: +"string"
```
  - addedInput schema / required
```
Added value: +[]
```
  - removedInput schema / title
```
Removed value: -"fetch_reportsArguments"
```
- Removedfetch_standups
- Addedlist_members
- Addedlist_polls
- Addedlist_standups
- Addedpost_report
2 tool updatesv1.0.0Mar 28, 2025
- First observedfetch_reports
- First observedfetch_standups

Deploy Server

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

TDQS

A3.9/5.0

Scored 2026-05-06 14:55 across 6 tools

Disambiguation5/5

Each tool targets a distinct resource or action: lists for polls, standups, and members; fetches for results and reports; and a single write tool. No two tools overlap in purpose.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern using snake_case (e.g., fetch_poll_results, list_standups), making naming predictable and easy to understand.

Tool Count5/5

With 6 tools, the set is well-scoped for a Geekbot integration, covering essential read operations and one write operation without being overly large or too small.

Completeness3/5

The tool set covers listing and fetching for polls and standups, but lacks create, update, or delete operations for polls and standups, and only includes one write tool (post_report). Notable gaps exist in managing resources.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
2145
Fathom MCP ServerOAuth
io.github.agencyenterprise
Connect Claude to Fathom meeting recordings, transcripts, and summaries
Communication App Automation Search
216
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
RootrOAuth
io.github.inspirio-co
Connect your team's living knowledge base — docs, data, issues, CRM — to Claude and ChatGPT.
RAG Systems Knowledge & Memory CRM
2

Related MCP Servers

MCP Relay Server
Communication App Automation
emiliobool
A
license
Not graded
quality
D
maintenance
This server allows integration with Discord, enabling message exchanges between Claude and a Discord channel using prompts and notifications.
Updated 2 years ago (2025-01-26 05:31 UTC)
12 npm
1
MIT
Notion MCP Server
Note Taking Content Management Systems App Automation
arre-ankit
A
license
Not graded
quality
D
maintenance
A simple server that integrates with Claude to allow querying and manipulating Notion pages and databases through natural language prompts.
Updated 2 years ago (2024-12-06 06:41 UTC)
4,521 npm
MIT
Inkeep MCP Serverofficial
RAG Systems Documentation Access
inkeep
A
license
Not graded
quality
D
maintenance
A server that connects Claude to your documentation via Inkeep's API, enabling AI-powered interactions with your documentation content.
Updated 2 years ago (2025-04-10 19:49 UTC)
25
MIT
Claudeus Plane MCP
Project Management Autonomous Agents
deus-h
F
license
Not graded
quality
D
maintenance
A server that bridges Claude AI with the Plane project management platform, enabling AI-powered project management tasks including project creation, task management, team collaboration, and automated workflows.
Updated 2 years ago (2025-01-31 08:56 UTC)
5
-

Geekbot MCP

主要特点✨

安装💻

通过 Smithery 安装

手动安装

配置⚙️

使用方法💡

工具🛠️

提示💬

提示💡

开发🧑‍💻

设置开发环境

运行测试✅

贡献🤝

许可证📜

致谢🙏

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Inkeep MCP Serverofficial