Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
SP_DB_DIRNoDirectory where the SQLite database file lives; set it to a volume./data (docker image) or . (bare binary)
SP_DB_URLNoPostgreSQL connection string (required when SP_DB_TYPE=postgres).
SP_DB_TYPENoDatabase type: 'sqlite' or 'postgres'.sqlite
SP_BASE_URLNoPublic URL used in links and notifications.http://localhost:4000
SP_LOG_LEVELNoLog level: debug, info, warn, error.info
SP_NODE_NAMENoWorker name, must match ^[a-z][a-z0-9-]{2,20}$; defaults to the hostname. Alternatively, pass --hostname to the server command.
SP_SERVER_LISTENNoListen address for the server.:4000

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
{}
prompts
{}
resources
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_checksA

List monitoring checks for the organization, optionally filtered by name/slug substring, labels, or check group. Returns {data, pagination}; pass pagination.cursor back as cursor for the next page. Use this for browsing or filtering a fleet of checks. To investigate a single check's current health, use diagnose_check instead; if you already know its UID or slug, get_check is more direct. Read-only: works with mcp:read tokens.

get_checkA

Get a single check's metadata by UID or slug; ask for extras with with=lastResult,lastStatusChange. For a full triage briefing (current status + recent results + active incidents), prefer diagnose_check; to search by name or label, use list_checks. Read-only: works with mcp:read tokens.

create_checkA

Create a new monitoring check and return it (uid, slug, placement, resolved periods). If you don't know what config shape a given type expects, call list_check_types with type first to fetch a working starting config, then use validate_check to dry-run before creating. An enabled check starts running on its next tick and opens an incident after its confirmation period; pass enabled:false to create it paused. A duplicate slug is rejected with a conflict, never merged — use update_check to change an existing check. Requires the mcp scope (mcp:read tokens are refused) and at least the user role in the organization.

update_checkA

Update an existing check by UID or slug and return the updated check. PATCH semantics — only the fields you pass are modified, others stay as-is. Use create_check to make a new check and delete_check to remove one; to pause without deleting, set enabled:false instead. Requires the mcp scope (mcp:read tokens are refused) and at least the user role in the organization.

delete_checkA

Soft-delete a monitoring check by UID or slug. The check stops running immediately, its active incidents are resolved and its scheduling jobs removed; historical results are kept. A check that other checks tunnel through is refused. To stop a check without losing it, use update_check with enabled:false instead. Returns {deleted: true, identifier}. Requires the mcp scope (mcp:read tokens are refused) and at least the user role in the organization.

validate_checkA

Dry-run validate a check config without creating or changing anything — a pure read, no side effects. Returns {valid, fields, warnings}: valid is false exactly when fields lists the blocking findings (every one of them, not just the first), while warnings are advisory notes that never block. Use this before create_check when you've assembled a config from scratch or modified a sample, to catch problems early. Read-only: works with mcp:read tokens.

run_checkA

Run a check once, now, in every region, instead of waiting for its next period (use it right after a fix, or on a freshly created check). The run goes through the normal result path: it can open or resolve an incident like any scheduled run. Rate limited per check and per organization. Returns {requestedAt, regions: [{region, status}]} where status is queued (due now, or right after the run in progress); read the outcome with diagnose_check or list_results (a result with periodStart >= requestedAt). Requires the mcp scope (mcp:read tokens are refused) and at least the user role in the organization.

diagnose_checkA

Return everything an operator would want to look at to diagnose a single check's current state in one call: current status, recent raw results across regions, any active incident, and the most recent resolved incident. Use this instead of chaining list_results + list_incidents when a human asks "what's wrong with check X?". Returns {check, freshness, regionalIssue, recentResults, activeIncident, lastResolvedIncident} — freshness and regionalIssue are omitted when there is nothing to report, the incidents are null when there are none. Read-only: works with mcp:read tokens.

list_resultsA

Query monitoring results (raw or aggregated) with filtering by check, type, status, region, period type, and time range. Use this for trend analysis or to inspect a specific window. For investigating a single check's current state, use diagnose_check instead. Returns {data, pagination, window, effectiveFilter}: data holds the result rows, window the time bounds actually queried, and effectiveFilter the period filter that ran after defaulting. Defaults: if periodType is omitted it falls back to "hour"; if periodStartAfter is omitted it falls back to a window matched to the finest periodType requested (raw=1h, hour=24h, day=30d, month=365d). Read-only: works with mcp:read tokens.

list_incidentsA

List internal incidents (active or resolved) for the organization, filtered by check, state, or time range. Returns {data, pagination} — total, size, and a cursor naming the last row of a full page; the cursor is not read back on the next call yet, so move forward by narrowing since/until. Use diagnose_check for one check's incidents plus current health in one call, and get_status_page include=incidents for the customer-facing entries on a status page. Read-only: works with mcp:read tokens.

get_incidentA

Get a single incident by UID; an unknown UID fails with an "incident not found" error. Returns the incident object — number, state, timestamps, failure counts — plus the check with with=check and up to 50 timeline events with with=events. include=["notifications"] adds the incident's notification attempts (one row per dispatch target with its delivery status, channel and recipient, newest first), filtered by status and capped by limit. Use list_incidents to search and filter across incidents, and diagnose_check for a check's full triage briefing. Read-only: works with mcp:read tokens.

list_check_typesA

List all monitoring check types supported by this server (e.g. http, tcp, dns, icmp, ssl), or with type, the ready-made sample configs of that type. Call it without arguments first when you don't know what type to use: it returns {data: [...]}, one entry per type with its description, enabled state, period bounds and secretFields. Then call it with type=: it returns {data: [...]} with one entry per matching type carrying its samples, each a complete, valid config to clone and modify (much more reliable than guessing field names). Read-only: works with mcp:read tokens.

list_regionsA

List monitoring regions available to the organization (e.g. eu-west-1, us-east-1). Returns {data: [...]} — each region's slug, label and per-region metadata — plus defaultRegions, the org's default placement set. Use these slugs in the regions array of create_check or update_check. Read-only: works with mcp:read tokens.

list_check_groupsA

List all check groups for the organization. Check groups bundle related checks together for shared incident handling and dashboard organization, and each entry carries its slug, rolled-up status and check count. Returns {data: [...]}. Read-only: works with mcp:read tokens.

probeA

Explore a target and test a js check before create_check, without saving anything. kind=script runs a js check script exactly as a SolidPing worker would and returns status, output (with console) and metrics; env carries plaintext parameters and secrets only NAMES the secret parameters, which run empty. kind=fetch GETs a URL from the server. kind=browser snapshots a page to pick selectors for browser steps. Reaches the URL or script target you name. Read-only: works with mcp:read tokens.

list_status_pagesA

List every status page in the organization, newest first, and return {data: [...]}. Use get_status_page for a single page by UID or slug (with=sections or include=sections for its contents). Read-only: works with mcp:read tokens.

get_status_pageA

Get one status page by UID or slug and return it. with=sections embeds its sections and their resources. include adds lists next to the page fields: "sections" (section metadata, display order), "resources" (the resources of the section named by sectionIdentifier) and "incidents" (the customer-facing incident publications on the page, filtered by state and active). Use list_status_pages to browse every page, and manage_status_page_section / _resource / _incident to change them. Read-only: works with mcp:read tokens.

create_status_pageA

Create a new status page for the organization and return the created page. A duplicate slug is rejected with a conflict, never merged. Only one page can be the default: the first page always becomes it, and isDefault:true demotes the previous default. Every new page is seeded with a default "Services" section and starts enabled and public — use manage_status_page_section to add more sections and update_status_page to edit the page later. Requires the mcp scope (mcp:read tokens are refused) and at least the user role in the organization.

update_status_pageA

Update an existing status page by UID or slug and return the updated page. PATCH semantics — only fields you pass change, omitted fields keep their current values; the page must already exist and a slug that collides with another page is rejected. Use create_status_page to make a new page and delete_status_page to remove one instead. Requires the mcp scope (mcp:read tokens are refused) and at least the user role in the organization.

delete_status_pageA

Soft-delete a status page by UID or slug: the page disappears from the API and the public site, taking its sections and resources with it, and its uploaded brand assets are deleted. There is no undelete — use update_status_page with enabled:false to take a page down without destroying it. Returns {deleted: true, identifier}. Use delete_status_page_section or delete_status_page_resource to remove part of a page instead. Requires the mcp scope (mcp:read tokens are refused) and at least the user role in the organization.

manage_status_page_sectionA

Create, update or delete a section of a status page. action=create adds a section (name and slug required) and returns it. action=update edits one (sectionIdentifier required; omitted fields are kept) and returns it. action=delete permanently removes a section and every resource pinned in it, returning {deleted, identifier}. Read a page's sections with get_status_page include=sections. Annotated destructive and non-idempotent because delete is one of its actions. Every action requires the mcp scope (mcp:read tokens are refused) and at least the user role in the organization.

manage_status_page_resourceA

Pin, edit or unpin a resource (a check or a check group) in a status page section. action=create pins exactly one of checkUid or checkGroupUid and returns the resource. action=update edits one (resourceUid required; omitted fields are kept). action=delete unpins it, returning {deleted, identifier}; the check or group itself is untouched. Read a section's resources with get_status_page include=resources. Annotated destructive and non-idempotent because delete is one of its actions. Every action requires the mcp scope (mcp:read tokens are refused) and at least the user role in the organization.

manage_status_page_incidentA

Manage the customer-facing incidents a status page shows (publications), distinct from the internal incidents list_incidents returns. Titles and bodies are shown to CUSTOMERS: never paste probe output, error strings, internal hostnames or IPs. action=create publishes a hand-written incident (pageIdentifier, title). action=update edits a publication's title, severity or state (pageIdentifier, publicationUid; PATCH semantics). action=add_update appends a narrative entry (pageIdentifier, publicationUid, kind, bodyMarkdown); entries are append-only. action=publish relays an EXISTING internal incident (incidentUid, pageIdentifier) with a title templated from the page. action=unpublish removes a relayed incident from the page (incidentUid, publicationUid), keeping the row for audit. create, add_update and publish notify status-page subscribers (hourly cap) and every action reaches webhook connections. Read publications with get_status_page include=incidents. Annotated destructive and non-idempotent because delete is one of its actions. Every action requires the mcp scope (mcp:read tokens are refused) and at least the user role in the organization.

Prompts

Interactive templates invoked by user choice

NameDescription
triage_incidentReview an incident and produce a triage summary. The model fetches the incident, its event timeline, the affected check's recent results, and returns a paragraph summarizing what's happening, the likely cause, and what to check next.
summarize_org_healthProduce a one-paragraph status summary of the organization's monitoring posture: which checks are failing, which incidents are active, overall posture.
draft_status_updateDraft a customer-facing status page update for an incident. The output is a draft for human review, not auto-published.

Resources

Contextual data attached and managed by the client

NameDescription
OrganizationCurrent organization metadata (slug, name).
RegionsAvailable monitoring regions.

TDQS

A4.4/5.0

Scored across 23 tools

Disambiguation5/5

Each tool targets a distinct resource and action, and the descriptions actively cross-reference each other (e.g. get_check vs diagnose_check vs list_results; list_incidents vs manage_status_page_incident for internal vs customer-facing incidents). The few superficially similar pairs are explicitly delineated, leaving little room for misselection.

Naming Consistency4/5

Nearly all tools follow a predictable verb_noun pattern (list_checks, get_check, create_check, update_check, delete_check, get_status_page, etc.). Minor deviations exist: the bare verb 'probe' breaks the pattern, and the manage_status_page_* tools use a 'manage' verb instead of the create/update/delete convention used elsewhere.

Tool Count4/5

At 23 tools the surface sits on the heavier end, but the domain genuinely spans several resource families (checks, results, incidents, status pages, sections, resources, publications), so most tools earn their place. A few consolidation candidates (e.g. the three manage_status_page_* tools) keep it just short of ideal.

Completeness4/5

Checks have full CRUD plus validate/run/diagnose, status pages and their sub-resources have full lifecycle coverage, and results/incidents/regions/types are sensibly read-only. Minor gaps exist (check groups are list-only, and internal incident state changes aren't exposed), but these are largely consistent with the domain's generated/read-mostly nature.

Maintenance

ActivityActive
ResponsivenessResponsive