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

긱봇 MCP

Geekbot MCP 로고 라이센스: MIT 파이썬 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를 원격 서버로 설치하려면:

지엑스피1

원격 서버는 각 릴리스마다 최신 버전으로 자동 업데이트됩니다.

Smithery의 데이터 정책 에 대한 자세한 정보

수동 설치

Python 3.10 이상 및 uv 필요합니다.

Python 3.10 이상을 설치하세요(아직 설치하지 않았다면):
- 맥OS:
  brew install python@3.10
  자세한 내용은 Homebrew Python 설치 가이드를 참조하세요.
- 우분투/데비안:
  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/웹훅 설정 에서 찾으세요.
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"
          }
        }
      }
    }

다음 사항을 반드시 교체하세요.

2단계에서 uv 실행 파일의 경로를 포함하는 UV-PATH
1단계의 Geekbot API 키를 사용하여 YOUR-API-KEY 입력하세요.

사용법 💡

구성이 완료되면 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일 이후에 Daily Standup 스탠드업에 제출된 모든 보고서를 받으세요."

사용 가능한 필터:

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에 보고서를 게시합니다.

예시 프롬프트: "안녕하세요, Daily Standup 스탠드업 보고서를 올려주시겠어요?"

반환된 데이터 필드:

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

기여하기 🤝

기여를 환영합니다! 저장소를 포크하고 변경 사항을 담은 풀 리퀘스트를 제출해 주세요.

라이센스 📜

이 프로젝트는 MIT 라이선스 에 따라 라이선스가 부여되었습니다.

감사의 말 🙏

Anthropic Model Context Protocol 프레임워크를 기반으로 구축되었습니다.
공식 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
-

긱봇 MCP

주요 특징 ✨

설치 💻

Smithery를 통해 설치

수동 설치

구성 ⚙️

사용법 💡

도구 🛠️

프롬프트 💬

팁 💡

개발 🧑‍💻

개발 환경 설정

테스트 실행 ✅

기여하기 🤝

라이센스 📜

감사의 말 🙏

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Inkeep MCP Serverofficial