Samuelz® Operations

List recorded rides in a time window

list_rides

Read-onlyIdempotent

Read at most 25 tenant-scoped reservations by pickup time in an explicit UTC window (max 7 days). Includes terminal reservations; never implies a unique current ride or complete history. No GPS, contacts, links or payment data. Use get_ride_status for recorded operational evidence.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "from": "<from>",
      "until": "<until>"
    },
    "name": "list_rides"
  }
}

Input Schema

Name	Required	Description	Default
`from`	Yes
`limit`	No
`until`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world, non-destructive), and the description layers on real behavioral constraints: result cap of 25, tenant scoping, a 7-day maximum window, inclusion of terminal reservations, and the explicit exclusion of GPS/contacts/links/payment data. This is context an agent could not get from the structured fields alone.

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?

Three tightly packed sentences with the core operation and its bounds front-loaded, then the caveats, then the sibling routing. No filler or restated fields.

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?

For a three-parameter, no-output-schema list tool, the description covers scope, safety-relevant exclusions, and the alternative tool. The main missing piece is what a returned reservation record contains beyond the excluded fields, plus default limit behavior.

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?

With 0% schema description coverage, the description must carry parameter meaning, and it does: it identifies the filter field as pickup time, requires an explicit UTC window, caps the window at 7 days, and echoes the limit ceiling of 25. It stops short of stating the default limit value or the ordering/pagination behavior, so a small gap remains.

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?

States a specific verb and resource ('Read ... tenant-scoped reservations by pickup time') plus hard scope bounds (at most 25, explicit UTC window, max 7 days). It explicitly separates itself from get_ride_status, so an agent can pick between them without inspecting either schema.

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

Usage Guidelines4/5

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

Names the alternative ('Use get_ride_status for recorded operational evidence') and implicitly rules out this tool for current-ride or full-history needs ('never implies a unique current ride or complete history'). Clear routing context, though it does not phrase the exclusions as an explicit 'do not use when' list.

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

All Samuelz® Operations tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?