Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

subway_available_times

Retrieve a Subway store's remaining pickup time slots for today by store ID. Returns RFC3339 UTC times with interval minutes, or an empty list when closed—clear capacity checks.

Instructions

Get one Subway store's available pickup times. Returns one Subway store's forward-looking pickup schedule -- every time slot the store is currently accepting orders for, as RFC3339 UTC instants, earliest first. Slots begin at the store's next orderable time (roughly half an hour out, not immediately) and run through closing, so the list reflects real remaining capacity for today rather than the store's advertised opening hours. Store IDs come from a GET /subway/store or GET /subway/nearby result's store_id field. A store that is closed or past its last slot for the day returns an empty slots array, which is a valid answer rather than an error. interval_minutes reports the spacing between consecutive slots as measured from the response itself.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum slots to return (1-200). Defaults to every slot the store offers.
store_idYesStore ID from a /subway/store or /subway/nearby result's store_id

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.16.2

TDQS

A4.2/5.0
Behavior5/5

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

With no annotations, the description carries the full transparency burden and handles it very well. It discloses the time format and ordering, the roughly half-hour offset from orderable time, that a closed store returns a valid empty list rather than an error, and the meaning of interval_minutes. These are non-obvious behaviors not captured in the schema.

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?

Every sentence is substantive and earns its place. The tool's action and scope are front-loaded in the first sentence, and the remaining details (time format, half-hour offset, empty-list behavior, interval_minutes) add critical context without fluff.

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

Completeness4/5

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

The description is highly complete for a tool with only two parameters and no output schema: it explains what the return data is, its ordering, time format, how to obtain store_id, and the empty-array case. A single gap is that it doesn't fully lay out the response envelope, but it names both key fields (slots and interval_minutes), making it sufficient for correct invocation.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description does not add new semantic meaning to the parameters: it reiterates that store_id comes from /subway/store or /subway/nearby results (already in the schema) and does not enrich the limit parameter beyond '1-200, defaults to every slot.'

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?

The description opens with a specific verb and resource: 'Get one Subway store's available pickup times.' It further clarifies that the tool returns the store's forward-looking pickup schedule as RFC3339 UTC instants, distinguishing it from tools that return store location, menu, or combo data.

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 description implies when to use the tool (when a Subway store's pickup times are needed) and explains that store IDs come from /subway/store or /subway/nearby results. However, it does not explicitly state when not to use it or compare it to sibling tools, leaving the routing decision mostly implicit.

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

Install Server

Other Tools