Skip to main content
Glama
remuzel

Polarsteps MCP Server

by remuzel

get_trip_log

Retrieve a summarized overview of a specific Polarsteps trip with timestamped steps, titles, descriptions, and locations to understand travel activities before accessing detailed information.

Instructions

Get an overview of the specific trip; this includes just a list of summarized steps, each including timestamp/title/description/location. Use this first for trip overviews before diving into detailed information.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
trip_idYesThe unique numerical identifier of a Polarsteps trip (typically 7+ digits)

Implementation Reference

  • The core handler function implementing the get_trip_log tool. It retrieves the trip using _get_trip, checks for validity and steps, constructs a log of steps as JSON-serializable dicts with timestamp, title, description, location, and returns them as TextContent.
    def get_trip_log(
        polarsteps_client: PolarstepsClient, input: GetTripLogInput
    ) -> list[TextContent]:
        trip = _get_trip(polarsteps_client, input.trip_id)
        if trip.id == -1:
            return single_text_content(f"Could not find trip with ID: {input.trip_id}")
        if trip.all_steps is None:
            return single_text_content(
                f"Trip with ID {input.trip_id} does not have any logged steps"
            )
    
        trip_log = [
            {
                "timestamp": step.timestamp,
                "title": step.name,
                "description": step.description,
                "location": f"{step.location.name} ({step.location.country_code})"
                if step.location
                else "Unknown",
            }
            for step in trip.all_steps
            if step.name is not None
        ]
        return [TextContent(type="text", text=json.dumps(trip)) for trip in trip_log]
  • Pydantic input schema for the get_trip_log tool, defining the required trip_id parameter with validation (integer >= 1,000,000).
    class GetTripLogInput(BaseModel):
        trip_id: int = Field(
            ...,
            description="The unique numerical identifier of a Polarsteps trip (typically 7+ digits)",
            ge=1_000_000,
        )
  • Tool registration within the PolarstepsTool enum, associating the name 'get_trip_log', its description, and input schema for MCP tool listing.
    TRIP_LOG = (
        "get_trip_log",
        "Get an overview of the specific trip; this includes just a list of summarized steps, each including timestamp/title/description/location. Use this first for trip overviews before diving into detailed information.",
        GetTripLogInput,
    )
  • MCP server tool dispatch/registration in call_tool handler, matching on TRIP_LOG enum and invoking the get_trip_log function with parsed input.
    case PolarstepsTool.TRIP_LOG:
        input = GetTripLogInput(**args)
        return get_trip_log(client, input)
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. While it describes the return format (summarized steps with specific fields), it doesn't address important behavioral aspects like whether this is a read-only operation, potential rate limits, authentication requirements, error conditions, or pagination behavior for large trips.

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 two sentences that each serve distinct purposes: the first states what the tool returns, the second provides usage guidance. It's front-loaded with the core functionality and avoids unnecessary verbiage.

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 single-parameter read operation with no output schema, the description provides adequate but incomplete context. It explains the return format and usage sequencing, but lacks information about error handling, response structure beyond field names, and behavioral constraints that would be important for an agent to use this tool 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% with the single parameter 'trip_id' well-documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, which is acceptable given the high schema coverage. The baseline of 3 is appropriate when the schema does the heavy lifting.

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: 'Get an overview of the specific trip' with specific content details ('list of summarized steps, each including timestamp/title/description/location'). It distinguishes from potential siblings by focusing on summarized overview rather than detailed information, though it doesn't explicitly name alternatives.

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 contextual guidance: 'Use this first for trip overviews before diving into detailed information.' This indicates when to use this tool (initial overview) versus alternatives (detailed information tools), though it doesn't explicitly name specific sibling tools or state when NOT to use it.

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