openbusdata

search_stops

Search for bus stops by name across timetable data. Returns matching stops with NaPTAN codes.

Instructions

Search for bus stops by name across all loaded timetable data. Returns matching stops with their NaPTAN codes.

Parameters: query: Substring to search for in stop names (case-insensitive).

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": {
      "query": "<query>"
    },
    "name": "search_stops"
  }
}

Input Schema

Name	Required	Description	Default
`query`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.2Jul 6, 2026

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so the description must convey behavioral traits. It states that the tool searches across all loaded timetable data and performs a case-insensitive substring match, which is relevant. However, it does not disclose whether the operation is read-only, any rate limits, or authentication requirements. For a simple search, this is adequate but not comprehensive.

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?

The description is extremely concise, with two short sentences that cover purpose, scope, return, and parameter meaning. Every sentence contributes value, and the most important information is front-loaded.

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?

Given that an output schema exists (as indicated by context signals), the description does not need to detail return values. It fully covers the tool's functionality and parameter semantics, making it complete for an AI agent to use correctly.

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 input schema only defines a 'query' parameter with no description, so the description compensates by explaining it is a case-insensitive substring search against stop names. This adds crucial semantic meaning beyond the schema.

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 specifies the verb 'search', the resource 'bus stops', and the scope 'across all loaded timetable data'. It also mentions the return of NaPTAN codes, distinguishing it from sibling tools like 'get_route_stops' or 'find_buses_by_arrival_time'.

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 description clearly states the tool's function (searching bus stops by name) and returns matching stops. While it does not explicitly state when not to use it or mention alternative tools, the sibling list provides context, and the description is sufficient for an agent to infer appropriate use.

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

Deploy Server