Skip to main content
Glama

Get STPT MCP service status

get_service_status
Read-onlyIdempotent

Verify STPT MCP service readiness and retrieve version, bundled network feed metadata, and bounded cache statistics for health checks without exposing secrets.

Instructions

Report server readiness, version, bundled network feed metadata, and bounded cache statistics. Contains no secrets.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
errorNoStructured failure, if any.
readyYes
cachesNo
statusYesOverall result status.
versionYes
timezoneYes
live_feedNoFreshness of the live arrivals feed. Null until a stop has been fetched.
provenanceNoSource and freshness metadata.
started_atNo
current_timeYes
network_feed_versionYes
network_generated_atYes
network_service_rangeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.3.7
    • addedOutput schema / $defs / Freshness
      Added value: +{
      +  "enum": [
      +    "fresh",
      +    "stale",
      +    "unverified"
      +  ],
      +  "title": "Freshness",
      +  "type": "string"
      +}
    • addedOutput schema / $defs / LiveFeedStatus
      Added value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "assessed_at": {
      +      "description": "When that fetch was assessed, in UTC.",
      +      "format": "date-time",
      +      "title": "Assessed At",
      +      "type": "string"
      +    },
      +    "clock_unchanged_seconds": {
      +      "description": "How long that stop's feed clock has stood still while real time advanced.",
      +      "minimum": 0,
      +      "title": "Clock Unchanged Seconds",
      +      "type": "number"
      +    },
      +    "freshness": {
      +      "$ref": "#/$defs/Freshness"
      +    },
      +    "recent_stops": {
      +      "additionalProperties": {
      +        "type": "integer"
      +      },
      +      "description": "Freshness of every stop fetched in the last 15 minutes, counted.",
      +      "propertyNames": {
      +        "$ref": "#/$defs/Freshness"
      +      },
      +      "title": "Recent Stops",
      +      "type": "object"
      +    },
      +    "skew_seconds": {
      +      "anyOf": [
      +        {
      +          "type": "number"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "default": null,
      +      "description": "The feed's implied clock minus the real clock, in seconds. Positive means the feed runs ahead. Null when the feed carried no clock reference.",
      +      "title": "Skew Seconds"
      +    },
      +    "stop_id": {
      +      "description": "Stop of the most recent live arrivals fetch.",
      +      "title": "Stop Id",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "stop_id",
      +    "assessed_at",
      +    "freshness",
      +    "clock_unchanged_seconds"
      +  ],
      +  "title": "LiveFeedStatus",
      +  "type": "object"
      +}
    • changedOutput schema / $defs / Provenance / properties / data_age_seconds / description
      Previous value: -"Age of the source/cache entry when returned."New value: +"Age of the upstream observation when returned, in seconds. Null when the age cannot be measured."
    • addedOutput schema / $defs / Provenance / properties / freshness
      Added value: +{
      +  "$ref": "#/$defs/Freshness",
      +  "default": "unverified",
      +  "description": "fresh: an upstream observation time was checked against this server's clock and is within tolerance. stale: the check failed (old, clock-skewed, or frozen data) or a cache entry past its TTL is served. unverified: the data carries no upstream clock reference (schedules, the network snapshot, alerts), so it cannot be confirmed as current."
      +}
    • changedOutput schema / $defs / Provenance / properties / is_stale / description
      Previous value: -"True when the stale cache policy supplied the data."New value: +"True when stale data is being returned, whether from cache or upstream."
    • changedOutput schema / $defs / Provenance / properties / observed_at / description
      Previous value: -"Upstream observation timestamp. Live arrivals expose no timestamp, so this is the fetch time; schedules describe future service and leave it null; vehicles use their upstream timestamp."New value: +"Upstream observation timestamp in UTC. Live arrivals derive it from the feed's own display times and remaining minutes; it is null when the feed carries no clock reference or is rejected as stale. Schedules describe future service and leave it null; vehicles use their upstream timestamp."
    • addedOutput schema / properties / live_feed
      Added value: +{
      +  "anyOf": [
      +    {
      +      "$ref": "#/$defs/LiveFeedStatus"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Freshness of the live arrivals feed. Null until a stop has been fetched."
      +}
  2. First observedv0.2.0

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered. The description adds genuine context beyond them: that the response includes bundled feed metadata and 'bounded' cache statistics, plus the assurance 'Contains no secrets,' which matters for an externally exposed status endpoint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no filler, and the primary payload (what is reported) is front-loaded before the safety note.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value details need not be in the description, and the annotations cover the safety contract. For a zero-parameter read-only status tool, nothing an agent needs in order to call it is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It correctly avoids inventing parameter semantics that do not exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Uses a specific verb ('Report') with a concrete list of resources: readiness, version, bundled network feed metadata, and bounded cache statistics. This is unmistakably a service-health tool and cannot be confused with any of the transit-data siblings such as get_vehicles or get_alerts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The stated contents imply a health/diagnostics use case, but the description never says when to call it, whether it should be polled, or how it relates to the sibling tools. Since no sibling covers the same ground, the missing guidance is less costly, leaving it at implied-only usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.