Skip to main content
Glama
KapilXDev
by KapilXDev

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
GITHUB_TOKENNoGitHub personal access token with Issues: read+write and Metadata: read permissions. If not set, GitHub tools return fixture data.
GITHUB_DEFAULT_REPONoDefault 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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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.

    Enforced by SQLite itself, not by string matching: the connection is
    opened read-only and an authorizer rejects every non-read action, so
    writes, DDL, PRAGMA and ATTACH all fail. Only one statement per call.

    Returns the column names, the rows, and whether the result was capped.
    
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.

    Refuses to double-book by default: if the slot overlaps an existing
    event the call fails and returns the conflicts, so you can pick another
    time (see find_free_slot) or retry with allow_conflict=true.
    
find_free_slotA

Find open slots of a given length within working hours.

    Returns the earliest candidates first, skipping times already in the
    past. Feed one of these straight into create_event.
    
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.

    Scope the search with a `repo:owner/name` qualifier unless the user
    genuinely wants results from the whole of GitHub.
    

Prompts

Interactive templates invoked by user choice

NameDescription
triage_issuesCross-reference open support tickets with GitHub issues and propose triage.
plan_my_weekReview the calendar and propose focus blocks around existing meetings.
customer_health_checkPull orders and tickets for one customer into a short health summary.

Resources

Contextual data attached and managed by the client

NameDescription
Workbench database schemaTables, columns, types, row counts and foreign keys.
Today's calendarEvery event scheduled for today, as JSON.

TDQS

A4.1/5.0

Scored across 12 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness3/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues