Skip to main content
Glama

Geekbot MCP

Logotipo de Geekbot MCP Licencia: MIT Python 3.10+ Versión de PyPI insignia de herrería

Desbloquea tus datos de Geekbot dentro de tus aplicaciones LLM 🚀

El servidor MCP (Protocolo de Contexto de Modelo) de Geekbot actúa como puente, conectando las aplicaciones cliente LLM (como Claude, Cursor, Windsurf, etc.) directamente con tu espacio de trabajo de Geekbot. Esto te permite interactuar con tus reuniones, informes y miembros del equipo de forma fluida en tus conversaciones usando lenguaje natural.

Características principales ✨

  • Accede a la información de las reuniones y encuestas : enumera todas las reuniones y encuestas en tu espacio de trabajo de Geekbot. 📊

  • Recuperar informes de reuniones y resultados de encuestas : obtenga informes y resultados de encuestas con filtros para reuniones específicas, usuarios o rangos de fechas. 📄

  • Ver miembros del equipo : obtén una lista de los miembros con los que colaboras en Geekbot. 👥

  • Publicar informes de stand-up : publica un informe de stand-up en Geekbot. 📝

Related MCP server: Notion MCP Server

Instalación 💻

Instalación mediante herrería

Para instalar Geekbot MCP como servidor remoto a través de Smithery :

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

El servidor remoto se actualizará automáticamente a la última versión con cada lanzamiento.

Más información sobre la Política de Datos de Smithery

Instalación manual

Requiere Python 3.10+ y uv .

  1. Instale Python 3.10+ (si aún no lo ha hecho):

  2. Instalar uv (si aún no lo has hecho):

    • macOS/Linux: En su terminal, ejecute el siguiente comando:

      curl -LsSf https://astral.sh/uv/install.sh | sh
    • Windows: en PowerShell, ejecute el siguiente comando:

      powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

    (Consulte los documentos de instalación de UV para obtener más opciones).

  3. Instalar/actualizar Geekbot MCP:

    • macOS/Linux: En su terminal, ejecute el siguiente comando:

      uv tool install --upgrade geekbot-mcp
    • Windows: en PowerShell, ejecute el siguiente comando:

      uv tool install --upgrade geekbot-mcp

Configuración ⚙️

Después de instalar Geekbot MCP, puede conectarlo a su aplicación de escritorio cliente LLM (por ejemplo, Claude Desktop, Cursor, Windsurf, etc.):

  1. Obtén tu clave API de Geekbot: encuéntrala en tu configuración de API/Webhooks de Geekbot 🔑.

  2. Encuentra la ruta del ejecutable uv :

  • Linux/macOS: En su terminal, ejecute el siguiente comando:

      which uv
  • Windows: en PowerShell, ejecute el siguiente comando:

      (Get-Command uv | Select-Object -ExpandProperty Path) -replace '\\', '\\'
  1. Configure su aplicación de escritorio cliente LLM: cada cliente LLM que admite MCP proporciona un archivo de configuración que puede editar para agregar el servidor Geekbot MCP.

Si está utilizando un cliente LLM diferente, consulte la documentación de su cliente para saber cómo configurar el servidor MCP.

Después de localizar el archivo de configuración, edítelo para agregar el servidor Geekbot MCP:

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

Asegúrese de reemplazar:

  • UV-PATH con la ruta a su ejecutable uv del paso 2

  • YOUR-API-KEY con tu clave API de Geekbot del paso 1

Uso 💡

Una vez configurada, su aplicación cliente LLM tendrá acceso a las siguientes herramientas e indicaciones para interactuar con sus datos de Geekbot:

Herramientas 🛠️

list_standups

Propósito: Enumera todas las reuniones disponibles mediante tu clave API. Útil para obtener una visión general o encontrar el ID de una reunión específica.

Ejemplo de mensaje: "Oye, ¿puedes enumerar mis reuniones de Geekbot?"

Campos de datos devueltos:

  • id : Identificador único de stand-up.

  • name : Nombre del standup.

  • channel : canal de comunicación asociado (por ejemplo, canal de Slack).

  • time : Hora programada para el informe de pie.

  • timezone : Zona horaria para la hora programada.

  • questions : Lista de preguntas realizadas en la reunión.

  • participants : Listado de usuarios que participan en el standup.

  • owner_id : ID del propietario del stand-up.

  • confidential : si la reunión es confidencial.

  • anonymous : Si el stand-up es anónimo.

list_polls

Propósito: Enumera todas las encuestas accesibles mediante tu clave API. Útil para obtener una visión general o encontrar el ID de una encuesta específica.

Ejemplo de mensaje: "Oye, ¿puedes enumerar mis encuestas de Geekbot?"

Campos de datos devueltos:

  • id : Identificador único de la encuesta.

  • name : Nombre de la encuesta.

  • time : Hora programada para la encuesta.

  • timezone : Zona horaria para la hora programada.

  • questions : Lista de preguntas realizadas en la encuesta.

  • participants : Lista de usuarios que participan en la encuesta.

  • creator : El creador de la encuesta.

fetch_reports

Propósito: Recupera informes específicos de reuniones. Puede filtrar por reunión, usuario y rango de fechas.

Ejemplos de indicaciones:

  • "Obtener los informes enviados ayer en la Retrospectiva".

  • "Muéstrame los informes del usuario John Doe para la reunión semanal de sincronización".

  • Reciba todos los informes enviados a la reunión diaria después del 1 de junio de 2024.

Filtros disponibles:

  • standup_id : Filtrar por un ID de standup específico.

  • user_id : Filtrar informes por un ID de usuario específico.

  • after : Recuperar informes enviados después de esta fecha (AAAA-MM-DD) 🗓️.

  • before : Recuperar informes enviados antes de esta fecha (AAAA-MM-DD) 🗓️.

Campos de datos devueltos:

  • id : Identificador único del informe.

  • reporter_name : Nombre del usuario que envió el informe.

  • reporter_id : ID del usuario que envió el informe.

  • standup_id : ID del standup al que pertenece el informe.

  • created_at : Marca de tiempo cuando se envió el informe.

  • content : Las respuestas/contenido reales del informe.

post_report

Propósito: Publica un informe en Geekbot.

Ejemplo de mensaje: "Oye, ¿puedes publicar el informe de la reunión diaria?"

Campos de datos devueltos:

  • id : Identificador único del informe.

  • reporter_name : Nombre del usuario que envió el informe.

  • reporter_id : ID del usuario que envió el informe.

  • standup_id : ID del standup al que pertenece el informe.

  • created_at : Marca de tiempo cuando se envió el informe.

  • content : Las respuestas/contenido reales del informe.

list_members

Propósito: enumera todos los miembros del equipo con los que compartes reuniones en tu espacio de trabajo de Geekbot.

Ejemplo de mensaje: "¿Quiénes son los miembros de mi espacio de trabajo de Geekbot?"

Campos de datos devueltos:

  • id : Identificador de miembro único.

  • name : Nombre completo del miembro.

  • email : Dirección de correo electrónico del miembro.

  • role : rol del miembro dentro de Geekbot (por ejemplo, administrador, miembro).

fetch_poll_results

Propósito: Recupera resultados específicos de una encuesta. Requiere un ID de encuesta y, opcionalmente, un rango de fechas.

Ejemplo de mensaje: "Oye, ¿qué se decidió sobre el nuevo logotipo en las encuestas de Geekbot?"

Campos de datos devueltos:

  • total_results : Número total de resultados.

  • question_results : Lista de resultados de preguntas.

Indicaciones 💬

weekly_rollup_report

Propósito: Genera un informe acumulativo semanal completo que resume las respuestas de las reuniones del equipo, destaca las actualizaciones clave, identifica los riesgos y las estrategias de mitigación, describe los próximos pasos y realiza un seguimiento de los próximos lanzamientos.

Consejos 💡

  • Revisar el uso de herramientas : Permite que el agente solicite tu aprobación explícita para cada acción de la herramienta y no permita llamadas automáticas. Esta función de seguridad te permite mantener el control sobre operaciones sensibles, especialmente al publicar informes en Geekbot. Se te solicitará que revises y apruebes cada llamada de herramienta antes de su ejecución, lo que ayuda a evitar envíos de datos no deseados.

  • Solicitar vista previa : Antes de publicar un informe, pídele al agente que lo previsualice, no que lo publique. Esto te dará la oportunidad de revisarlo y asegurarte de que sea correcto o modificarlo antes de publicarlo en Geekbot.

  • Limite el volumen de datos recuperados : Si utiliza la herramienta fetch_reports , limite el intervalo de fechas a un período razonable. Esto ayudará a evitar que el agente recupere una gran cantidad de datos y cause problemas de rendimiento. Tenga en cuenta que el agente aplicará límites a la cantidad de informes que puede recuperar.

Argumentos:

  • standup_id : ID del standup a incluir en el informe acumulativo.

Desarrollo 🧑‍💻

¿Está interesado en contribuir o ejecutar el servidor localmente?

Configurar el entorno de desarrollo

# 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

Ejecución de pruebas ✅

# Ensure dependencies are installed (uv sync)
pytest

Contribuyendo 🤝

¡Agradecemos sus contribuciones! Por favor, bifurquen el repositorio y envíen una solicitud de incorporación de cambios.

Licencia 📜

Este proyecto está licenciado bajo la licencia MIT .

Agradecimientos 🙏

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
NameRequiredDescriptionDefault
poll_idYesID of the specific standup to fetch reports for. If not provided, reports for all standups will be fetched.
beforeNoFetch results before this date (format: YYYY-MM-DD). This is not provided unless explicitly asked by the user.
afterNoFetch 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
NameRequiredDescriptionDefault
standup_idNoID of the specific standup to fetch reports for. If not provided, reports for all standups will be fetched.
user_idNoID of the specific user to fetch reports for. If not provided, reports for all members will be fetched.
afterNoFetch reports after this date (format: YYYY-MM-DD)
beforeNoFetch 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
NameRequiredDescriptionDefault

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
NameRequiredDescriptionDefault

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
NameRequiredDescriptionDefault

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
NameRequiredDescriptionDefault
standup_idYesID of the specific standup to post the report to.
answersYesAn 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.

  1. 7 tool updatesv0.3.4
    • 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. 2 tool updatesv1.0.0
    • First observedfetch_reports
    • First observedfetch_standups

TDQS

A3.9/5.0

Scored 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

Related MCP Connectors

Related MCP Servers

  • 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.
    12 npm
    1
    MIT
  • 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.
    25
    MIT
  • 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.
    5
    -