Skip to main content
Glama
Sign In
mcp-route-master

mcp-route-master

by CoderShivamGusain
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Read a captured booking page

read_page
Read-onlyIdempotent

Interprets a captured redBus or MakeMyTrip booking page and returns step-specific meaning—ranked bus options, seat maps, missing passenger details, or payment totals—for booking guidance.

Instructions

Read a booking page captured from the user's browser and return what it means for this step.

Works on redBus and MakeMyTrip. Results page: ranked bus list. Seat page: seat diagram (plus the boarding/drop points on MakeMyTrip). Points page: numbered boarding and drop points. Passenger page: what's still missing, or the booking summary to confirm. Payment page: the total, the hold time and the "Pay here" link. Nothing is stored.

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": {
      "capture": "<capture>"
    },
    "name": "read_page"
  }
}

Input Schema

NameRequiredDescriptionDefault
captureYesExactly the JSON the capture script returned (page_action action='capture').
sort_byNoResults page: how to sort.best
bus_typeNoResults page: what the user wants.any
operatorNoSeat page: the bus's operator, for the heading.
departureNoSeat page: the bus's departure time.
around_timeNoResults page: preferred departure, HH:MM.
preferencesNoSeat page: window, aisle, front, back, together, lower, upper, cheapest, sleeper, seater.
seats_wantedNoSeat page: how many seats the user needs.
approved_fareNoPayment page: the fare the user confirmed.
requested_seatsNoPassenger page: the seats the user chose, in the site's own numbering.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world. Beyond that, the description discloses supported sites (redBus, MakeMyTrip), which page types produce which outputs, and that nothing is persisted. Good added context, though it doesn't cover failure or ambiguous-capture behavior.

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

Conciseness4/5

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

Front-loaded one-sentence purpose followed by a compact, scannable page-type catalog, then a short state note. Each line carries distinct information, though 'Nothing is stored' largely restates readOnlyHint.

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?

With 10 parameters and no output schema, the description does the heavy lifting by describing what each page type returns, which roughly substitutes for a return-value spec. It omits what happens on unrecognized or stale captures, which would matter for an agent parsing arbitrary browser output.

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 coverage is 100% and the schema already labels each parameter by page type (e.g. 'Results page: how to sort', 'Seat page: how many seats'). The description's page-type list aligns with those groupings but adds no new meaning such as defaults, precedence, or format details.

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?

Specific verb+resource ('Read a booking page captured from the user's browser') plus an explicit statement of what it returns ('what it means for this step'). The page-type catalog further pins down scope in a way an agent can immediately match to its situation.

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?

The per-page-type breakdown implicitly tells the agent when this tool applies (results, seat, points, passenger, payment pages) and names the supported sites. It stops short of naming the capture/action sibling or stating when not to use it, so the routing decision is inferred rather than spelled out.

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

Deploy Server

Other Tools