SolidPing
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SP_DB_DIR | No | Directory where the SQLite database file lives; set it to a volume. | /data (docker image) or . (bare binary) |
| SP_DB_URL | No | PostgreSQL connection string (required when SP_DB_TYPE=postgres). | |
| SP_DB_TYPE | No | Database type: 'sqlite' or 'postgres'. | sqlite |
| SP_BASE_URL | No | Public URL used in links and notifications. | http://localhost:4000 |
| SP_LOG_LEVEL | No | Log level: debug, info, warn, error. | info |
| SP_NODE_NAME | No | Worker name, must match ^[a-z][a-z0-9-]{2,20}$; defaults to the hostname. Alternatively, pass --hostname to the server command. | |
| SP_SERVER_LISTEN | No | Listen 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
| Capability | Details |
|---|---|
| tools | {} |
| prompts | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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 |
| 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 |
| 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
| Name | Description |
|---|---|
| triage_incident | Review 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_health | Produce a one-paragraph status summary of the organization's monitoring posture: which checks are failing, which incidents are active, overall posture. |
| draft_status_update | Draft 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
| Name | Description |
|---|---|
| Organization | Current organization metadata (slug, name). |
| Regions | Available monitoring regions. |
TDQS
Scored across 23 tools
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.
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.
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.
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.