Skip to main content
Glama
Pranav-Karra-3301

CATA Bus MCP Server

search_stops_tool

Find bus stops by name or ID to get location details for CATA bus routes in State College, PA.

Instructions

Search for stops by name or ID.

Args: query: Search query string to match against stop names, IDs, or descriptions

Returns: List of matching stops with their ID, name, latitude, and longitude

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The main handler function for the 'search_stops_tool' MCP tool. It is registered via the @mcp.tool decorator, ensures GTFS data is initialized, and calls the search_stops helper function.
    @mcp.tool
    async def search_stops_tool(query: str) -> list[dict[str, Any]]:
        """Search for stops by name or ID.
    
        Args:
            query: Search query string to match against stop names, IDs, or descriptions
    
        Returns:
            List of matching stops with their ID, name, latitude, and longitude
        """
        await ensure_initialized()
        if not gtfs_data or not gtfs_data.stops:
            return []
        return await search_stops(gtfs_data, query)
  • Core helper function that implements the stop search logic: performs case-insensitive substring matching on stop_id, stop_name, stop_code, and stop_desc, collects matching stops, and sorts them by name.
    async def search_stops(gtfs_data: GTFSData, query: str) -> list[dict[str, Any]]:
        """
        Search for stops by name or ID.
    
        Args:
            gtfs_data: The GTFS static data.
            query: Search query string.
    
        Returns:
            List of matching stops with id, name, latitude, and longitude.
        """
        query_lower = query.lower()
        results = []
    
        for stop_id, stop in gtfs_data.stops.items():
            # Search in stop ID, name, code, and description
            if (
                query_lower in stop.stop_id.lower()
                or query_lower in stop.stop_name.lower()
                or (stop.stop_code and query_lower in stop.stop_code.lower())
                or (stop.stop_desc and query_lower in stop.stop_desc.lower())
            ):
    
                results.append(
                    {
                        "stop_id": stop.stop_id,
                        "name": stop.stop_name,
                        "lat": stop.stop_lat,
                        "lon": stop.stop_lon,
                    }
                )
    
        # Sort by name for consistency (use empty string for None)
        results.sort(key=lambda x: str(x.get("name") or ""))
        return results
  • Type signature of the tool handler defining input (query: str) and output (list[dict[str, Any]]) schema.
    async def search_stops_tool(query: str) -> list[dict[str, Any]]:
Behavior2/5

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

No annotations are provided, so the description carries full burden. While it mentions the tool searches and returns a list, it doesn't disclose important behavioral traits like whether this is a read-only operation, if there are rate limits, authentication requirements, or how results are sorted/paginated. The description is minimal on behavioral context.

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?

The description is appropriately concise with clear sections for Args and Returns. Both sentences earn their place by explaining the parameter and return value. However, the structure could be slightly improved by integrating the information more fluidly rather than as separate labeled sections.

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?

Given the tool has an output schema (which handles return values) and only one parameter with decent semantic coverage in the description, the description is moderately complete. However, for a search tool with no annotations, it lacks important context about search behavior, limitations, and when to use versus siblings.

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 compensates well by explaining that the 'query' parameter matches against stop names, IDs, or descriptions. This adds meaningful semantic context beyond the bare schema type, though it doesn't specify format examples or search behavior details.

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 clearly states the tool's purpose as searching for stops by name or ID, which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'list_routes_tool' or 'vehicle_positions_tool' that might also involve stop-related data.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. With siblings like 'list_routes_tool' and 'next_arrivals_tool' that might involve stops, there's no indication of when search is preferred over listing or when other tools might be more appropriate.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Pranav-Karra-3301/catabus-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server