Skip to main content
Glama
remuzel

Polarsteps MCP Server

by remuzel

get_trips

Fetch recent trips from a Polarsteps user's travel history with summary details like names, dates, duration, and basic statistics. Control the number of trips retrieved to browse travel history or find trip IDs for further exploration.

Instructions

Fetch a list of a user's recent trips with summary information including trip names, dates, duration, and basic stats. Ideal for browsing someone's travel history or finding trip IDs for detailed exploration. Use n_trips parameter to control how many recent trips to retrieve (default: 5).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
usernameYesThe Polarsteps username whose trips you want to retrieve
n_tripsNoMaximum number of recent trips to return (ordered by most recent first)

Implementation Reference

  • The core handler function for the 'get_trips' tool. Retrieves the user's trips via _get_user helper, checks if trips exist, and returns JSON-serialized summaries of the most recent n_trips (default 5) as TextContent objects.
    def get_trips(
        polarsteps_client: PolarstepsClient, input: GetTripsInput
    ) -> list[TextContent]:
        user = _get_user(polarsteps_client, input.username)
        if user.alltrips is None:
            return single_text_content(
                f"No trips found for user with username={input.username}"
            )
        return [
            TextContent(type="text", text=json.dumps(trip.to_summary()))
            for trip in user.alltrips[: input.n_trips]
        ]
  • Pydantic model defining the input schema for the get_trips tool, with required 'username' and optional 'n_trips' (default 5, min 1) fields.
    class GetTripsInput(BaseModel):
        username: str = Field(
            ..., description="The Polarsteps username whose trips you want to retrieve"
        )
        n_trips: int = Field(
            5,
            ge=1,
            description="Maximum number of recent trips to return (ordered by most recent first)",
        )
  • Registration of the 'get_trips' tool in the PolarstepsTool Enum, providing the tool name, description, and input schema for MCP server tool listing.
    TRIPS = (
        "get_trips",
        "Fetch a list of a user's recent trips with summary information including trip names, dates, duration, and basic stats. Ideal for browsing someone's travel history or finding trip IDs for detailed exploration. Use n_trips parameter to control how many recent trips to retrieve (default: 5).",
        GetTripsInput,
    )
  • Dispatch logic in the MCP server's call_tool handler that invokes the get_trips function with parsed input when the 'get_trips' tool is called.
    case PolarstepsTool.TRIPS:
        input = GetTripsInput(**args)
        return get_trips(client, input)
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool fetches 'recent trips' with a default ordering ('most recent first') and a default parameter value, which adds useful context. However, it lacks details on potential errors (e.g., invalid username), rate limits, or authentication needs, leaving gaps for a tool with no annotation coverage.

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 appropriately sized and front-loaded, with the first sentence stating the core purpose and the second providing usage context and parameter guidance. Every sentence earns its place by adding value without unnecessary repetition or fluff.

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's moderate complexity (2 parameters, no output schema, no annotations), the description is partially complete. It covers the purpose and basic usage but lacks details on output format, error handling, or behavioral constraints. Without annotations or an output schema, more context would be helpful for an agent to use it effectively.

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 schema already fully documents both parameters. The description adds marginal value by mentioning the 'n_trips' parameter controls how many recent trips to retrieve and its default, but this is redundant with the schema's default and description. No additional semantic context is provided beyond what the schema offers.

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 clearly states the verb ('Fetch') and resource ('list of a user's recent trips'), specifying what summary information is included (trip names, dates, duration, basic stats). It distinguishes from siblings like 'get_trip' (singular) by emphasizing it retrieves multiple trips for browsing history, not detailed exploration.

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 provides clear context for when to use this tool ('Ideal for browsing someone's travel history or finding trip IDs for detailed exploration'), implying it's for summary-level data. However, it does not explicitly state when not to use it or name alternatives among siblings like 'search_trips' for filtered searches, leaving some ambiguity.

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/remuzel/polarsteps-mcp'

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