ai-l1-support-agent
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LLM_MODEL | No | Model name to use with the LLM provider. | |
| LLM_API_KEY | No | API key for the LLM provider (if required). | |
| LLM_BASE_URL | No | Base URL for the LLM API (e.g., LM Studio endpoint). | |
| LLM_PROVIDER | No | The LLM provider to use. Defaults to a rule-based provider for tests and reproducible demo. | |
| LLM_REASONING | No | Reasoning effort setting for the LLM (e.g., 'none'). | |
| TICKET_SOURCE | No | Source of tickets: 'fixture' for local snapshot or 'remote' for public MockAPI. | fixture |
| TICKETS_API_URL | No | Base URL for the tickets API used in generated links. | |
| ALLOW_REMOTE_WRITES | No | If 'true', allows remote writes (reserved safeguard; currently not implemented). | false |
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 |
|---|---|
| tickets_list_newA | List tickets whose effective status is |
| tickets_getA | Get one source ticket with local agent classification, replies and status overlay. |
| tickets_update_classificationA | Persist agent classification locally without rewriting source labels. |
| tickets_add_replyA | Add a local mock reply and either wait for the user or close the ticket. |
| tickets_change_statusA | Change status in the local overlay; the public MockAPI remains untouched. |
| knowledge_searchA | Search published Markdown articles by title, keywords and body tokens. |
| knowledge_get_articleA | Read one published knowledge article by its stable ID. |
| knowledge_create_draftA | Create a local create/update draft that cannot bypass human review. |
| telegram_notify_l2A | Write a concise L2 escalation into the mock Telegram outbox. |
| github_create_bugA | Create a linked mock GitHub Issue without inventing missing logs or context. |
| feedback_addA | Add a mock user, L2 or developer response linked to the original ticket. |
| feedback_listA | List mock user and engineer responses for a ticket in chronological order. |
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 12 tools
Each tool targets a distinct action within its domain: ticket management, knowledge lookup, notification, bug creation, and feedback. The descriptions clearly differentiate overlapping concepts like tickets_add_reply vs feedback_add and update_classification vs change_status.
Tools largely follow a domain_verb_noun pattern (tickets_add_reply, knowledge_get_article, github_create_bug). Minor exceptions like feedback_add/feedback_list (implicit object) and tickets_list_new (adjective instead of noun) create slight inconsistency but remain predictable.
The 12 tools cover a well-scoped support agent workflow: ticket triage, knowledge access, escalation, bug reporting, and feedback. The count is within the ideal range and each tool serves a clear purpose.
Core ticket operations are covered, but there is no way to list tickets by status other than 'new', which prevents the agent from resuming work on in-progress or waiting tickets. Knowledge draft creation exists without management (list/update), leaving an incomplete workflow.