goby-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GOBY_API_KEY | No | Goby API key (gk_...). If not set, the server uses a stored project token or default token. | |
| GOBY_BASE_URL | No | Base URL of the Goby instance (e.g. https://acme.goby.chat). | |
| GOBY_MCP_CONFIG | No | Path to the config file storing tokens. Overrides the default ~/.config/goby-mcp/config.json. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| whoamiA | Verify the Goby API key and learn which team it belongs to, its task key prefix (e.g. OPS), the key's scopes and whose access it borrows. |
| list-statusesA | The team's board columns — the legal status values for create-task / update-task / list-tasks. |
| list-membersA | The team's members — legal assignee values. Prefer matching people by email; names can be ambiguous. |
| list-labelsA | Labels in use on the team's tasks (harvested from existing tasks — Goby has no labels endpoint, so a label nobody has used yet will not appear). |
| list-tasksA | List the team's tasks, newest-updated first. Completed tasks are excluded unless include_done is true. All filters are optional and combine with AND (status/status_in union; assignee/unassigned union). |
| get-taskA | Fetch one task by its key (e.g. OPS-42), including its description. |
| create-taskA | Create a Goby task. The key (e.g. OPS-43) is assigned by the server. Status, assignees and labels accept friendly values (semantic/name, email/name, label name) as well as uuids. Goby has no issue types or sprints — use priority (1 highest … 3) and labels. |
| update-taskB | Update any subset of a task's fields (PATCH semantics: omitted fields are untouched). Use the clear_* flags to clear a field. Editing requires the key's owner to be a participant or a team lead. |
| get-commentsA | The task's conversation, oldest first (user, agent and system messages). Needs the comments:read scope. |
| add-commentA | Post a comment on a task. By default the comment is written WITHOUT waking the Goby agent (no provider spend) — set start_agent_run=true to have the agent respond, exactly as if a person typed into the thread. Needs the comments:write scope. A comment still moves a todo task to in_progress. |
| get-task-historyA | A task's recorded workflow changes (status, assignee, due date), newest first. Carries no message content. |
| list-webhooksB | This team's webhook endpoints. Needs the webhooks:write scope. |
| create-webhookA | Register an HTTPS endpoint to receive task events. The signing secret is returned ONCE here and can never be read back — store it. Needs the webhooks:write scope. |
| update-webhookA | Update a webhook's name, url, events or enabled flag (any subset). Re-enable an auto-disabled endpoint with enabled=true after fixing the receiver. |
| delete-webhookA | Delete a webhook endpoint permanently (this is also how you rotate a secret: delete, then create again). |
| list-project-tokensA | Show which Goby token (masked) is active for the current project directory, where it came from, and every stored per-project token. Use this first when a Goby call fails with unauthorized or 'no token configured'. |
| set-project-tokenA | Store a Goby API key for a project directory so every Goby tool run from that directory (or any subdirectory) uses it. Takes effect immediately, no restart. Tokens are written to the user's config file, never into the repo. |
| remove-project-tokenA | Forget the stored Goby token for a project directory (defaults to the current one). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 18 tools
Every tool targets a distinct concern: auth introspection, task CRUD, comments, webhooks, and project tokens. The list_* getters are clearly separated by noun (statuses, members, labels, tasks), so there is no meaningful overlap or ambiguity.
Naming is highly predictable: list-* for reads, get-* for single resources, create-/update-/delete- for mutations, and add- for comments. The one outlier, whoami, is a conventional CLI-style name and does not create confusion.
18 tools is on the higher side but justified: task management, comments, history, webhooks, and token management each need their own surface. There are no redundant tools, though a few administrative helpers could potentially be consolidated.
The core domain is well covered: task CRUD (minus explicit deletion/archival), comments, history, webhooks, and token configuration. Missing task delete/archive and comment edit/delete are minor gaps, and webhook delivery inspection would round it out, but the main workflows are complete.