mcp-app-harness
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_HOST | No | HTTP transport bind host | 0.0.0.0 |
| MCP_PORT | No | HTTP transport bind port | 9000 |
| APP_DB_PATH | No | SQLite path for the app (`/data/...` to persist on a volume) | :memory: |
| APP_BASE_URL | No | Where the harness reaches the app | http://localhost:8080 |
| MCP_TRANSPORT | No | `stdio` (embedded) or `http` (sandboxed port) | stdio |
| HARNESS_FIXTURE | No | Baseline for `populate()` | fixtures/seed_baseline.json |
| APP_HTTP_TIMEOUT | No | Client timeout (short, so a wedged app fails fast) | 10 |
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
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_ticketB | Open a new support ticket. priority ∈ low|normal|high|urgent. |
| list_ticketsA | List tickets, optionally filtered by status (open|in_progress|closed). |
| get_ticketB | Fetch a single ticket by id. |
| assign_ticketC | Assign a ticket to someone; moves it to in_progress. |
| close_ticketD | Close a ticket. |
| populateC | Reset the app and load the deterministic baseline fixture. |
| snapshotB | Capture the full application state as a JSON document. |
| restoreC | Overwrite application state with a previously captured snapshot. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| all_tickets | Live view of every ticket — handy as read-only context for an agent. |
| app_health | Liveness of the application under test. |
TDQS
Scored across 8 tools
Each tool has a clearly distinct purpose: ticket tools (create, read, update status, list) and state management tools (populate, restore, snapshot) operate on different aspects with no overlap.
Ticket tools follow consistent verb_noun pattern (e.g., create_ticket), but state management tools use single-word verbs (populate, restore, snapshot), creating a minor inconsistency in naming conventions.
8 tools is well-scoped for a ticket system with testing utilities; each tool earns its place without being excessive or insufficient.
Core ticket lifecycle is covered (create, get, list, assign, close), but missing update for other fields (e.g., priority, description) and no reopen functionality, leaving notable gaps.