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

mcp-route-master

by CoderShivamGusain
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Check a bus operator

check_operator
Read-onlyIdempotent

Vet bus operator listings for trustworthiness using visible details: detect real RTC operators and copycats, weight ratings by review count, and flag highway boarding or mislabeled sleeper buses.

Instructions

Check whether a bus operator/listing looks trustworthy.

Detects real government (RTC) operators and copycat names, weighs the rating by the number of reviews, and flags highway boarding points and 'semi-sleeper' listings sold as sleepers. Uses only what the user can see on the listing; it does not look anything up online.

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": {
      "operator_name": "<operator_name>"
    },
    "name": "check_operator"
  }
}

Input Schema

NameRequiredDescriptionDefault
ratingNoStar rating shown on the listing (0-5), if known.
bus_typeNoBus type text from the listing, e.g. 'Volvo 9600 A/C Semi Sleeper (2+2)'.
review_countNoNumber of ratings/reviews shown, if known.
operator_nameYesOperator name exactly as shown on the booking site, e.g. 'HRTC' or 'Laxmi Holidays Pvt Ltd'.
boarding_pointNoBoarding point shown on the listing, if known.
has_live_trackingNoWhether the listing shows live tracking, if known.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.0

TDQS

A3.6/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=false; the description reinforces the closed-world claim by saying it never looks anything up online. Beyond that it discloses the actual heuristics applied — rating weighted by review volume, copycat detection against RTC, boarding-point and bus-type flags — which is real behavioral context an agent cannot get from structured fields. It does not describe the shape of the verdict (confidence, issue list), leaving a small gap.

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?

Two short paragraphs, front-loaded with the verdict intent and followed by the concrete detection signals. Every clause carries information about behavior; there is no filler or restatement of the title. Slightly list-like in the second sentence but still efficient.

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

Completeness3/5

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

For a six-parameter, read-only analysis tool with no output schema, the description covers the inputs and detection logic well but never hints at the return shape — whether the result is a boolean, a trust score, or a list of flags. Since there is no output schema to compensate, that is a meaningful omission for an agent deciding how to use the result.

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 and the schema already does the heavy lifting on all six fields. The description does add some meaning by revealing how fields are consumed — rating is weighed against review_count, bus_type drives the semi-sleeper check, boarding_point drives the highway flag. has_live_tracking is never mentioned, and no format guidance beyond the schema is offered.

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

Purpose4/5

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

The description gives a specific verb and resource: "Check whether a bus operator/listing looks trustworthy," and enumerates the exact signals examined (RTC authenticity, copycat names, rating vs review count, highway boarding points, mislabeled semi-sleepers). An agent can tell this is an assessment/flagging tool rather than a search or ranking tool. It stops short of naming siblings such as check_booking_safety or rank_buses, so differentiation is inferred rather than stated.

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 scope constraint "Uses only what the user can see on the listing; it does not look anything up online" usefully tells the agent what inputs it may pass and what it must not expect. However, there is no explicit statement of when to call this versus check_booking_safety or rank_buses, and no prerequisite workflow (e.g., read the page first) is described. Usage is implied by the tool's domain rather than guided.

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