Skip to main content
Glama
shomechakraborty

Scientific Tools MCP Server

scientific_data

Retrieve real-time scientific data: earthquakes, air quality, solar events, and NASA imagery. Supports geographic filtering by location and date range.

Instructions

Fetch real-time scientific data from major public APIs. Datasets: earthquakes (USGS), air_quality (OpenAQ), solar_events (NASA DONKI), nasa_apod. Supports geographic filtering by lat/lon/radius. Returns structured, agent-ready data.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
datasetYesScientific dataset to retrieve
locationNoLocation for spatially-filtered queries (city name, lat/lon, or country code)
latitudeNoLatitude for geographic queries
longitudeNoLongitude for geographic queries
radius_kmNoSearch radius in km around lat/lon (default: 500)
date_fromNoStart date YYYY-MM-DD (default: 7 days ago)
date_toNoEnd date YYYY-MM-DD (default: today)
min_magnitudeNoMinimum earthquake magnitude (for earthquakes dataset)
max_resultsNoMaximum results to return (default: 10)

Implementation Reference

  • Main async handler function for the scientific_data tool. Dispatches to internal fetchers based on the 'dataset' parameter (earthquakes, solar_events, nasa_apod, air_quality). Returns structured JSON responses or error dicts.
    async def scientific_data_handler(arguments: dict) -> dict:
        dataset = arguments.get("dataset", "")
    
        if not dataset:
            return {"error": "dataset parameter is required"}
    
        async with aiohttp.ClientSession() as session:
            if dataset == "earthquakes":
                return await _fetch_earthquakes(session, arguments)
            elif dataset == "solar_events":
                return await _fetch_solar_events(session, arguments)
            elif dataset == "nasa_apod":
                return await _fetch_nasa_apod(session, arguments)
            elif dataset == "air_quality":
                return await _fetch_air_quality(session, arguments)
            else:
                return {"error": f"Unknown dataset: {dataset}", "available_datasets": [
                    "earthquakes", "air_quality", "solar_events", "nasa_apod"
                ]}
  • Input schema defining the tool's parameters: dataset (enum), location, latitude, longitude, radius_km, date_from, date_to, min_magnitude, max_results. The 'dataset' field is required.
    TOOL_SCHEMA = {
        "type": "object",
        "properties": {
            "dataset": {
                "type": "string",
                "enum": [
                    "earthquakes",
                    "air_quality",
                    "solar_events",
                    "nasa_apod",
                    "climate_normals",
                ],
                "description": "Scientific dataset to retrieve",
            },
            "location": {
                "type": "string",
                "description": "Location for spatially-filtered queries (city name, lat/lon, or country code)",
            },
            "latitude": {"type": "number", "description": "Latitude for geographic queries"},
            "longitude": {"type": "number", "description": "Longitude for geographic queries"},
            "radius_km": {
                "type": "number",
                "description": "Search radius in km around lat/lon (default: 500)",
                "default": 500,
            },
            "date_from": {"type": "string", "description": "Start date YYYY-MM-DD (default: 7 days ago)"},
            "date_to": {"type": "string", "description": "End date YYYY-MM-DD (default: today)"},
            "min_magnitude": {
                "type": "number",
                "description": "Minimum earthquake magnitude (for earthquakes dataset)",
                "default": 4.0,
            },
            "max_results": {
                "type": "integer",
                "description": "Maximum results to return (default: 10)",
                "default": 10,
            },
        },
        "required": ["dataset"],
    }
  • Registers the tool with the registry, providing name, description, input_schema, price_per_call_usd, stripe_price_id, handler function reference, and category.
    def register(registry) -> None:
        from server import ToolDefinition
        registry.register(ToolDefinition(
            name=TOOL_NAME,
            description=(
                "Fetch real-time scientific data from major public APIs. "
                "Datasets: earthquakes (USGS), air_quality (OpenAQ), "
                "solar_events (NASA DONKI), nasa_apod. "
                "Supports geographic filtering by lat/lon/radius. "
                "Returns structured, agent-ready data."
            ),
            input_schema=TOOL_SCHEMA,
            price_per_call_usd=TOOL_PRICE_USD,
            stripe_price_id=TOOL_STRIPE_PRICE,
            handler=scientific_data_handler,
            category="earth_science",
        ))
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 disclosure. It states the tool fetches data and returns structured data but omits details about rate limits, authentication requirements, or any potential side effects. It adequately describes the retrieval nature but lacks depth.

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 concise with two well-structured sentences. The first sentence defines the tool's purpose, and the second adds key details (datasets, filtering, output type). It is efficient but could be slightly tighter by integrating the dataset list into the first sentence.

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

Completeness4/5

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

Given the tool's complexity (9 parameters, no output schema), the description covers the main capabilities: datasets, geographic filtering, and data readiness. However, it lacks details on the return format for each dataset, which would be helpful given the absence of an output schema.

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 baseline is 3. The description adds minimal value beyond the schema by summarizing capabilities like geographic filtering, but does not elaborate on parameter formats or dependencies. The schema already provides clear parameter descriptions.

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 tool fetches real-time scientific data from major APIs and lists specific datasets (earthquakes, air_quality, etc.), providing a specific verb and resource that distinguishes it from sibling tools like analytics or compound_lookup.

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

Usage Guidelines3/5

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

The description implies usage for fetching scientific data with geographic filtering but lacks explicit guidance on when to use this tool versus alternatives or any when-not-to-use conditions. No exclusions or prerequisites are mentioned.

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/shomechakraborty/mcp-scientific-tools'

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