internal-ops
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OPS_DB_PATH | No | Path to the SQLite database file. Defaults to data/ops.db. | data/ops.db |
| OPS_MCP_TOKEN | No | Optional token for authentication. When set, every tool call must pass this same value as access_token. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Northline Goods is a fictional company. These tools read a local help center and ticket queue. Quote the article id you used. When the server process has OPS_MCP_TOKEN set, pass that same value as access_token on every tool call.
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 |
|---|---|
| search_docsC | Search Northline help-center articles by keyword. |
| get_docA | Fetch one help-center article, including its full markdown body. |
| list_open_ticketsA | List tickets that are still open. Resolved and pending tickets are omitted. |
| get_ticketB | Fetch one ticket, including its description and latest note. |
| create_ticketB | Open a new ticket. The ticket is stored with status open. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| ops_stats | JSON counts of help-center articles and open tickets. |
TDQS
Scored across 5 tools
The tool set splits cleanly into two resource families (docs and tickets), and within each family the actions are distinct: search_docs searches while get_doc fetches a single article, and list_open_tickets lists while get_ticket and create_ticket operate on a single ticket. No two tools could reasonably be confused for one another.
All five tools follow a strict snake_case verb_noun pattern (search_docs, get_doc, list_open_tickets, get_ticket, create_ticket), with verbs that accurately signal the operation. The only variance is the natural doc/docs singular-plural distinction, which is idiomatic rather than inconsistent.
Five tools is on the lean side but every tool serves a distinct purpose and none is redundant. It is slightly thin for an 'internal-ops' surface that touches both documentation and ticketing, but well within a reasonable scope.
The ticket lifecycle is a dead end: tickets can be created and read, but there is no update, close, resolve, or comment/note operation, so an agent cannot act on the tickets it lists. The docs side is read-only, which is plausible for a help center but leaves no way to enumerate articles beyond keyword search.