workbench MCP server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GITHUB_TOKEN | No | GitHub personal access token with Issues: read+write and Metadata: read permissions. If not set, GitHub tools return fixture data. | |
| GITHUB_DEFAULT_REPO | No | Default repository for GitHub tools (e.g., 'your-name/scratch-repo'). Must be set to enable live GitHub issue creation and comments. |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_tablesA | List the tables in the workbench database. Call this first if you do not already know what data is available. |
| describe_schemaA | Describe columns, types and foreign keys for one table or all tables. Always call this before writing SQL -- do not guess column names. |
| run_queryA | Run one read-only SELECT against the workbench database. |
| list_eventsA | List calendar events in a date range, earliest first. Use this to answer questions about what is on the calendar, and before scheduling anything, so you know what is already booked. |
| create_eventA | Create a calendar event. |
| find_free_slotA | Find open slots of a given length within working hours. |
| delete_eventA | Delete a calendar event by id. Confirm with the user before calling. |
| list_issuesA | List issues in a repository, newest first. Pull requests are filtered out -- GitHub returns them from the issues endpoint too, and they are almost never what you want here. |
| get_issueA | Fetch one issue in full, including its body. |
| create_issueA | Open a new issue. This posts publicly -- confirm with the user first. Include enough context in the body that someone who was not part of this conversation can act on it. |
| comment_on_issueA | Add a comment to an existing issue. Posts publicly -- confirm first. |
| search_issuesA | Search issues across GitHub using its query syntax. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| triage_issues | Cross-reference open support tickets with GitHub issues and propose triage. |
| plan_my_week | Review the calendar and propose focus blocks around existing meetings. |
| customer_health_check | Pull orders and tickets for one customer into a short health summary. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Workbench database schema | Tables, columns, types, row counts and foreign keys. |
| Today's calendar | Every event scheduled for today, as JSON. |
TDQS
Scored across 12 tools
The tools form three clear clusters—database, calendar, and GitHub issues—and within each cluster every tool has a distinct resource and action. Even similar-sounding tools like list_events vs find_free_slot and list_issues vs search_issues are clearly separated by their descriptions.
All tool names follow a consistent lowercase snake_case verb_noun pattern, such as list_tables, create_event, delete_event, and get_issue. The singular/plural distinction (list_issues vs get_issue) is also applied predictably.
Twelve tools is well within the ideal range, and each tool serves a distinct, justified purpose across the three subdomains. There is no apparent bloat or redundancy.
The database read-only surface is complete, and calendar/issue creation and reading are covered, but there are notable gaps: no event update/reschedule tool and no issue update/close tool. Agents can work around some gaps but cannot fully manage issue state or reschedule events cleanly.