generated: '2026-08-09'
method: derived
source: mcp/atmospore-pollen-forecasts-mcp.yml + openapi/atmospore-pollen-forecasts-openapi-original.json
description: >-
  Binds every Atmospore MCP tool to the OpenAPI operation that backs it, so each tool inherits
  a real input contract from the spec instead of a guessed one. Atmospore is an unusually clean
  case: the MCP surface and the REST surface are 1:1 — four tools, four operations, no MCP-only
  composites and no orphan REST operations.
surfaces:
  openapi:
    file: openapi/atmospore-pollen-forecasts-openapi-original.json
    source: https://pollenapi.com/openapi.json
    version: 3.0.3
    gated: false
    operations: 4
  mcp:
    url: https://mcp.atmospore.com/mcp
    gated: true
    gate: >-
      tools/list returns JSON-RPC -32001 without an API key, so live inputSchema introspection
      was not possible. Tool names and parameters were read from the first-party open-source
      server (github.com/atmospore/atmospore-mcp), which is the same product.
    tools: 4
  graphql:
    present: false
crosswalk:
  - tool: get_pollen
    category: forecast
    rest: [getPollenForecast]
    rest_path: GET /v1/pollen
    binding: rest
    confidence: high
    parameter_mapping:
      lat: lat
      lon: lon
      forecast_days: forecast_days
    note: >-
      The REST operation additionally requires `dt` (start date, YYYY-MM-DD) and accepts an
      optional `species` filter. The MCP tool exposes neither — it defaults dt server-side and
      always returns all species, so the tool is a narrower projection of the operation.
  - tool: get_top_species
    category: forecast
    rest: [getPollenTop]
    rest_path: GET /v1/pollen-top
    binding: rest
    confidence: high
    parameter_mapping:
      lat: lat
      lon: lon
      limit: null
    note: >-
      `limit` has no OpenAPI counterpart on /v1/pollen-top — the documented REST parameters are
      lon, lat, dt and forecast_days only. The MCP tool truncates the ranked list client-side.
      The REST `dt`/`forecast_days` range controls are not exposed as tool arguments.
  - tool: get_area_average
    category: forecast
    rest: [getPollenArea]
    rest_path: GET /v1/pollen-area
    binding: rest
    confidence: medium
    parameter_mapping:
      lat: lat
      lon: lon
      radius_km: radius
      forecast_days: forecast_days
    note: >-
      UNIT MISMATCH: the MCP tool takes `radius_km` (default 25) while the REST operation takes
      `radius` in METRES (default 25000, max 50000). An agent that reads the OpenAPI and the
      tool schema together will get this wrong unless the conversion is stated. The tool also
      pins the species filter to the tree_tot/grass_tot/weed_tot aggregates rather than exposing
      the operation's free-form `species` list.
  - tool: list_supported_species
    category: metadata
    rest: [getSpecies]
    rest_path: GET /v1/species
    binding: rest
    confidence: high
    parameter_mapping: {}
    note: >-
      The only unauthenticated operation on the API (security: [] in the spec). Cacheable —
      the live response carries Cache-Control max-age=86400 and the docs advise caching it
      client-side.
mcp_only: []
rest_only: []
coverage:
  tools_named: 4
  tools_bound: 4
  mcp_only: 0
  rest_operations_total: 4
  rest_operations_with_tool: 4
  binding_confidence: {high: 3, medium: 1, low: 0}
divergences:
  - kind: unit-mismatch
    detail: get_area_average.radius_km (kilometres) vs getPollenArea.radius (metres)
  - kind: parameter-omission
    detail: >-
      No MCP tool exposes `dt`, so an agent cannot ask for a historic or explicitly-dated
      forecast through MCP even though REST supports it.
  - kind: parameter-without-backing
    detail: get_top_species.limit has no REST equivalent; it is applied by the server wrapper.