Geekbot MCP
OfficialGeekbot MCP
Разблокируйте данные Geekbot в своих приложениях LLM 🚀
Сервер Geekbot MCP (Model Context Protocol) действует как мост, соединяя клиентские приложения LLM (например, Claude, Cursor, Windsurf и т. д.) напрямую с вашим рабочим пространством Geekbot. Это позволяет вам беспрепятственно взаимодействовать со стендапами, отчетами и членами команды в рамках ваших разговоров, используя естественный язык.
Основные характеристики ✨
Доступ к информации о стендапах и опросах : список всех стендапов и опросов в вашем рабочем пространстве Geekbot. 📊
Извлечение отчетов о стендапах и результатов опросов : извлечение отчетов и результатов опросов с помощью фильтров по определенным стендапам, пользователям или диапазонам дат. 📄
Просмотр участников команды : получите список участников, с которыми вы сотрудничаете в Geekbot. 👥
Публикуйте стендап-отчеты : публикуйте стендап-отчеты на Geekbot. 📝
Related MCP server: Notion MCP Server
Установка 💻
Установка через Smithery
Чтобы установить Geekbot MCP в качестве удаленного сервера через Smithery :
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 .
Убунту/Дебиан:
sudo apt update sudo apt install python3.10Windows: Загрузите и установите с Python.org .
Более подробную информацию см. в руководстве по установке Python для Windows .
Установите uv (если вы этого еще не сделали):
macOS/Linux: В терминале выполните следующую команду:
curl -LsSf https://astral.sh/uv/install.sh | shWindows: в PowerShell выполните следующую команду:
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
(Дополнительные параметры см. в документации по установке УФ-ламп .)
Установка/обновление Geekbot MCP:
macOS/Linux: В терминале выполните следующую команду:
uv tool install --upgrade geekbot-mcpWindows: в PowerShell выполните следующую команду:
uv tool install --upgrade geekbot-mcp
Конфигурация ⚙️
После установки Geekbot MCP вы можете подключить его к своему клиентскому настольному приложению LLM (например, Claude Desktop, Cursor, Windsurf и т. д.):
Получите свой ключ API Geekbot: найдите его в настройках API/Webhooks Geekbot 🔑.
Найдите путь к исполняемому файлу
uv:
Linux/macOS: В терминале выполните следующую команду:
which uvWindows: в PowerShell выполните следующую команду:
(Get-Command uv | Select-Object -ExpandProperty Path) -replace '\\', '\\'
Настройте клиентское настольное приложение LLM: каждый клиент LLM, поддерживающий MCP, предоставляет файл конфигурации, который можно редактировать, чтобы добавить сервер 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с путем к исполняемому файлуuvиз шага 2YOUR-API-KEYс вашим ключом API Geekbot из шага 1
Использование 💡
После настройки ваше клиентское приложение LLM получит доступ к следующим инструментам и подсказкам для взаимодействия с данными Geekbot:
Инструменты 🛠️
list_standups
Назначение: Перечисляет все стендапы, доступные через ваш ключ API. Полезно для получения обзора или поиска определенного идентификатора стендапа.
Пример запроса: «Эй, можешь перечислить мои стендапы Geekbot?»
Возвращаемые поля данных:
id: Уникальный идентификатор стендапа.name: Название выступления.channel: связанный канал связи (например, канал Slack).time: Запланированное время для стендап-отчета.timezone: часовой пояс для запланированного времени.questions: Список вопросов, заданных в ходе выступления.participants: Список пользователей, участвующих в стендапе.owner_id: идентификатор владельца стендапа.confidential: является ли стендап конфиденциальным.anonymous: Является ли стендап анонимным.
list_polls
Назначение: Перечисляет все опросы, доступные через ваш ключ API. Полезно для получения обзора или поиска определенного идентификатора опроса.
Пример запроса: «Эй, можешь перечислить мои опросы Geekbot?»
Возвращаемые поля данных:
id: Уникальный идентификатор опроса.name: Название опроса.time: Запланированное время для опроса.timezone: часовой пояс для запланированного времени.questions: Список вопросов, заданных в опросе.participants: Список пользователей, участвующих в опросе.creator: Создатель опроса.
fetch_reports
Назначение: Извлекает определенные отчеты о стендапах. Вы можете фильтровать по стендапу, пользователю и диапазону дат.
Примеры подсказок:
«Загрузить отчеты, представленные вчера в ретроспективе».
«Покажите мне отчеты пользователя Джона Доу для стендапа «Weekly Sync».
«Получите все отчеты, отправленные в Daily Standup после 1 июня 2024 года».
Доступные фильтры:
standup_id: Фильтрация по определенному идентификатору стендапа.user_id: Фильтрация отчетов по определенному идентификатору пользователя.after: Получить отчеты, отправленные после этой даты (ГГГГ-ММ-ДД) 🗓️.before: Получить отчеты, отправленные до указанной даты (ГГГГ-ММ-ДД) 🗓️.
Возвращаемые поля данных:
id: Уникальный идентификатор отчета.reporter_name: Имя пользователя, отправившего отчет.reporter_id: идентификатор пользователя, отправившего отчет.standup_id: идентификатор стендапа, к которому относится отчет.created_at: временная метка отправки отчета.content: Фактические ответы/содержание отчета.
post_report
Цель: Публикация отчета в Geekbot.
Пример запроса: «Эй, можешь опубликовать отчет о стендапе Daily Standup?»
Возвращаемые поля данных:
id: Уникальный идентификатор отчета.reporter_name: Имя пользователя, отправившего отчет.reporter_id: идентификатор пользователя, отправившего отчет.standup_id: идентификатор стендапа, к которому относится отчет.created_at: временная метка отправки отчета.content: Фактические ответы/содержание отчета.
list_members
Назначение: Составляет список всех членов команды, с которыми вы делитесь стендапами в вашем рабочем пространстве Geekbot.
Пример запроса: «Кто является участниками моего рабочего пространства Geekbot?»
Возвращаемые поля данных:
id: Уникальный идентификатор участника.name: Полное имя участника.email: адрес электронной почты участника.role: Роль участника в Geekbot (например, Администратор, Участник).
fetch_poll_results
Назначение: Извлекает конкретные результаты опроса. Требуется идентификатор опроса и, опционально, диапазон дат.
Пример вопроса: «Эй, какое решение было принято по поводу нового логотипа в опросах Geekbot?»
Возвращаемые поля данных:
total_results: Общее количество результатов.question_results: Список результатов вопросов.
Подсказки 💬
weekly_rollup_report
Цель: создание комплексного еженедельного сводного отчета, в котором обобщаются ответы команды на стычках, освещаются ключевые обновления, определяются риски и стратегии их смягчения, излагаются дальнейшие шаги и отслеживаются предстоящие запуски.
Советы 💡
Обзор использования инструмента : заставьте агента запрашивать ваше явное одобрение для каждого действия инструмента и не разрешайте автоматические вызовы инструментов. Эта функция безопасности гарантирует, что вы сохраните контроль над конфиденциальными операциями, особенно при отправке отчетов в Geekbot. Вам будет предложено просмотреть и одобрить каждый вызов инструмента перед выполнением, что поможет предотвратить непреднамеренную отправку данных.
Запросить предварительный просмотр : Перед публикацией отчета попросите агента просмотреть отчет, а не публиковать его. Это даст вам возможность просмотреть отчет и убедиться в его правильности или внести в него изменения перед публикацией в Geekbot.
Ограничьте объем извлекаемых данных : если вы используете инструмент
fetch_reports, ограничьте диапазон дат разумным периодом. Это поможет предотвратить извлечение агентом большого объема данных и возникновение проблем с производительностью. Имейте в виду, что агент будет применять ограничения на количество отчетов, которые он может извлечь.
Аргументы:
standup_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Вношу свой вклад 🤝
Вклады приветствуются! Пожалуйста, сделайте форк репозитория и отправьте запрос на извлечение с вашими изменениями.
Лицензия 📜
Данный проект лицензирован в соответствии с лицензией MIT .
Благодарности 🙏
Создан на основе протокола контекста антропной модели .
Использует официальный API Geekbot .
Available Tools
6 toolsfetch_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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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.
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.
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.
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.
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.
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.
| 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
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.
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.
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.
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.
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.
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 updates
v0.3.4- Added
fetch_poll_results - Changed
fetch_reports15 fields changed- removed
Input schema / properties / after / defaultRemoved value: -null - added
Input schema / properties / after / descriptionAdded value: +"Fetch reports after this date (format: YYYY-MM-DD)" - removed
Input schema / properties / after / titleRemoved value: -"After" - removed
Input schema / properties / before / defaultRemoved value: -null - added
Input schema / properties / before / descriptionAdded value: +"Fetch reports before this date (format: YYYY-MM-DD)" - removed
Input schema / properties / before / titleRemoved value: -"Before" - removed
Input schema / properties / standup_id / defaultRemoved value: -null - added
Input schema / properties / standup_id / descriptionAdded value: +"ID of the specific standup to fetch reports for. If not provided, reports for all standups will be fetched." - removed
Input schema / properties / standup_id / titleRemoved value: -"Standup Id" - removed
Input schema / properties / user_id / defaultRemoved value: -null - added
Input schema / properties / user_id / descriptionAdded value: +"ID of the specific user to fetch reports for. If not provided, reports for all members will be fetched." - removed
Input schema / properties / user_id / titleRemoved value: -"User Id" - changed
Input schema / properties / user_id / typePrevious value: -"integer"New value: +"string" - added
Input schema / requiredAdded value: +[] - removed
Input schema / titleRemoved value: -"fetch_reportsArguments"
- Removed
fetch_standups - Added
list_members - Added
list_polls - Added
list_standups - Added
post_report
2 tool updates
v1.0.0- First observed
fetch_reports - First observed
fetch_standups
TDQS
Scored across 6 tools
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.
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.
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.
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
Related MCP Connectors
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Connect Claude to Fathom meeting recordings, transcripts, and summaries
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Connect your team's living knowledge base — docs, data, issues, CRM — to Claude and ChatGPT.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceThis server allows integration with Discord, enabling message exchanges between Claude and a Discord channel using prompts and notifications.12 npm1MIT
- AlicenseNot gradedqualityDmaintenanceA simple server that integrates with Claude to allow querying and manipulating Notion pages and databases through natural language prompts.4,521 npmMIT

Inkeep MCP Serverofficial
AlicenseNot gradedqualityDmaintenanceA server that connects Claude to your documentation via Inkeep's API, enabling AI-powered interactions with your documentation content.25MIT- FlicenseNot gradedqualityDmaintenanceA 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.5-