Skip to main content
Glama
jagan-shanmugam

Climatiq MCP Server

travel-spend

Calculate carbon emissions from travel spending by inputting spend type, amount, currency, location, and year to assess environmental impact.

Instructions

Calculate carbon emissions from travel-related spending based on spend type, amount, currency, location, and year.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
spend_typeYesType of travel spending (air, road, rail, sea, hotel)
moneyYesAmount of money spent
money_unitYesCurrency unit for the spent money
spend_locationYesLocation of the travel spending
spend_yearNoYear of the travel spending

Implementation Reference

  • Main handler function for the 'travel-spend' tool. Validates inputs, constructs request to Climatiq API endpoint '/travel/v1-preview1/spend', processes response, generates summary text, and handles caching.
    async def travel_spend_tool(config, arguments, server, climatiq_request):
        """
        Calculate carbon emissions from travel-related spending.
        
        This tool uses a spend-based method to estimate emissions from various travel activities:
        - Air travel spending
        - Road travel spending (including taxis)
        - Rail travel spending
        - Sea travel spending
        - Hotel accommodation spending
        
        The calculation uses economic input-output models to estimate the carbon intensity
        of different travel services based on financial spend data.
        """
        spend_type = arguments.get("spend_type")
        money = arguments.get("money")
        money_unit = arguments.get("money_unit")
        spend_location = arguments.get("spend_location")
        spend_year = arguments.get("spend_year")
        
        if not spend_type or not money or not money_unit or not spend_location:
            raise ValueError("Missing required parameters for travel spend calculation")
            
        # Validate spend type
        valid_spend_types = ["air", "road", "rail", "sea", "hotel"]
        if spend_type.lower() not in valid_spend_types:
            raise ValueError(f"Invalid spend_type: {spend_type}. Must be one of: {', '.join(valid_spend_types)}")
            
        # Construct the request to the Climatiq API
        request_data = {
            "spend_type": spend_type.lower(),
            "money": money,
            "money_unit": money_unit,
            "spend_location": spend_location
        }
        
        if spend_year:
            request_data["spend_year"] = spend_year
            
        try:
            result = await climatiq_request("/travel/v1-preview1/spend", request_data)
            
            # Store in cache
            cache_id = f"travel_spend_{spend_type}_{money}_{money_unit}_{id(result)}"
            
            co2e = result.get("co2e", 0)
            co2e_unit = result.get("co2e_unit", "kg")
            location_name = result.get("spend_location", {}).get("name", "unknown location")
            
            spend_type_display = spend_type.capitalize()
            result_text = f"{spend_type_display} travel spending of {money} {money_unit} in {location_name} "
            result_text += f"results in {co2e} {co2e_unit} of CO2e emissions."
            result_text += f"\n\nDetailed results are available as a resource with ID: {cache_id}"
            
            return result_text, result, cache_id
            
        except ValueError as e:
            error_text = f"Error calculating travel spend emissions: {str(e)}"
            return error_text, None, None
  • Schema definition for the 'travel-spend' tool, including input schema, description, and parameters.
    types.Tool(
        name="travel-spend",
        description="Calculate carbon emissions from travel-related spending based on spend type, amount, currency, location, and year.",
        inputSchema={
            "type": "object",
            "properties": {
                "spend_type": {"type": "string", "description": "Type of travel spending (air, road, rail, sea, hotel)"},
                "money": {"type": "number", "description": "Amount of money spent"},
                "money_unit": {"type": "string", "description": "Currency unit for the spent money"},
                "spend_location": {"type": "string", "description": "Location of the travel spending"},
                "spend_year": {"type": "number", "description": "Year of the travel spending"},
            },
            "required": ["spend_type", "money", "money_unit", "spend_location"],
        },
    )
  • MCP server registration of tools via list_tools handler, which returns all tool definitions including 'travel-spend' from get_tool_definitions() in tools.py.
    @server.list_tools()
    async def handle_list_tools() -> list[types.Tool]:
        """
        List available tools for interacting with the Climatiq API.
        """
        return get_tool_definitions()
  • Dispatch logic in the generic call_tool handler that routes 'travel-spend' calls to the travel_spend_tool function.
    elif name == "travel-spend":
        result_text, result, cache_id = await travel_spend_tool(config, arguments, server, climatiq_request)
  • Import of the travel_spend_tool handler and get_tool_definitions for tool registration from tools.py.
    from climatiq_mcp_server.tools import (
        set_api_key_tool,
        electricity_emission_tool,
        travel_emission_tool,
        search_emission_factors_tool,
        custom_emission_calculation_tool,
        cloud_computing_emission_tool,
        freight_emission_tool,
        procurement_emission_tool,
        hotel_emission_tool,
        travel_spend_tool,
        get_tool_definitions
    )
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. It describes what the tool does (calculation) but doesn't mention important behavioral aspects: whether it's a read-only operation, what format the output takes, whether it requires authentication (like 'set-api-key'), accuracy limitations, or rate limits. For a calculation tool with zero annotation coverage, this is insufficient.

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 a single, efficient sentence that front-loads the core purpose. It lists all parameters without unnecessary elaboration. While it could potentially be more structured, every word serves a purpose and there's no wasted text.

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

Completeness2/5

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

For a calculation tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (emissions in what units?), how accurate the calculation is, what data sources are used, or whether authentication is required despite 'set-api-key' being a sibling tool. The agent lacks crucial context for proper tool invocation.

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 documents all 5 parameters thoroughly. The description lists the same parameters ('spend type, amount, currency, location, and year') but doesn't add meaningful semantic context beyond what's in the schema descriptions. It doesn't explain how these parameters interact or affect the calculation.

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: 'Calculate carbon emissions from travel-related spending' with specific parameters listed. It uses a clear verb ('calculate') and identifies the resource ('carbon emissions'), but doesn't explicitly differentiate from sibling tools like 'travel-emission' or 'hotel-emission' which might have overlapping functionality.

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?

No guidance is provided about when to use this tool versus alternatives. The description lists parameters but doesn't indicate prerequisites, appropriate contexts, or when to choose this over sibling tools like 'travel-emission' or 'custom-emission-calculation'. The agent must infer usage from the parameter list alone.

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/jagan-shanmugam/climatiq-mcp-server'

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