Skip to main content
Glama

nasa_neo

Search for asteroids near Earth by date range or specific ID to monitor potential impact risks using NASA's Near Earth Object data.

Instructions

Near Earth Object Web Service - information about asteroids

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
start_dateYesStart date for asteroid search (YYYY-MM-DD)
end_dateYesEnd date for asteroid search (YYYY-MM-DD)
asteroid_idNoID of a specific asteroid

Implementation Reference

  • Core handler function `nasaNeoHandler` that executes the nasa_neo tool logic: fetches NEO data by date range or asteroid ID from NASA API, stores as resource, formats output.
    export async function nasaNeoHandler(params: NeoParams) {
      try {
        // If we're looking for a specific asteroid by ID
        if (params.asteroid_id) {
          const endpoint = `/neo/rest/v1/neo/${params.asteroid_id}`;
          const result = await nasaApiRequest(endpoint, {});
          
          // Store the result as a resource
          addResource(`nasa://neo/${params.asteroid_id}`, {
            name: `Asteroid: ${result.name}`,
            mimeType: 'application/json',
            text: JSON.stringify(result, null, 2)
          });
          
          // Return formatted result
          return {
            content: [
              {
                type: "text",
                text: formatSingleAsteroidText(result)
              }
            ],
            isError: false
          };
        }
        
        // Default to today if no dates specified
        let startDate = params.start_date;
        let endDate = params.end_date;
        
        if (!startDate) {
          const today = new Date();
          startDate = today.toISOString().split('T')[0];
        }
        
        // If no end_date, use start_date (same day)
        if (!endDate) {
          endDate = startDate;
        }
        
        // API limits feed to 7 days
        const maxDays = 7;
        const start = new Date(startDate);
        const end = new Date(endDate);
        const daysDiff = Math.floor((end.getTime() - start.getTime()) / (1000 * 60 * 60 * 24));
        
        if (daysDiff > maxDays) {
          return {
            content: [
              {
                type: "text",
                text: `Error: Date range too large. NEO feed is limited to ${maxDays} days.`
              }
            ],
            isError: true
          };
        }
        
        // Call the NASA NEO API
        const endpoint = `/neo/rest/v1/feed?start_date=${startDate}&end_date=${endDate}`;
        const result = await nasaApiRequest(endpoint, {});
        
        // Process and format the results
        return processNeoFeedResults(result, startDate, endDate);
      } catch (error: any) {
        console.error('Error in NEO handler:', error);
        
        return {
          content: [
            {
              type: "text",
              text: `Error retrieving NEO data: ${error.message}`
            }
          ],
          isError: true
        };
      }
    }
  • Zod schema `neoParamsSchema` defining input parameters for the nasa_neo tool.
    export const neoParamsSchema = z.object({
      start_date: z.string().optional(),
      end_date: z.string().optional(),
      asteroid_id: z.string().optional()
    });
  • src/index.ts:728-748 (registration)
    Tool `nasa_neo` definition and input schema in the `tools/list` handler response.
      name: "nasa_neo",
      description: "Near Earth Object Web Service - information about asteroids",
      inputSchema: {
        type: "object",
        properties: {
          start_date: {
            type: "string",
            description: "Start date for asteroid search (YYYY-MM-DD)"
          },
          end_date: {
            type: "string",
            description: "End date for asteroid search (YYYY-MM-DD)"
          },
          asteroid_id: {
            type: "string",
            description: "ID of a specific asteroid"
          }
        },
        required: ["start_date", "end_date"]
      }
    },
  • src/index.ts:1496-1509 (registration)
    Direct MCP request handler registration for method `nasa/neo`, dispatching to `handleToolCall`.
    // NEO Handler
    server.setRequestHandler(
      z.object({ 
        method: z.literal("nasa/neo"),
        params: z.object({
          start_date: z.string().optional(),
          end_date: z.string().optional(),
          asteroid_id: z.string().optional()
        }).optional()
      }),
      async (request) => {
        return await handleToolCall("nasa/neo", request.params || {});
      }
    );
  • src/index.ts:1853-1895 (registration)
    Dynamic handler loading in `handleToolCall`: imports `./handlers/nasa/neo.js` and calls default export (`nasaNeoHandler`) for `nasa_neo` tool.
    if (internalToolId.startsWith("nasa/")) {
      // Extract the NASA API endpoint name
      const endpoint = internalToolId.split("/")[1];
      const normalizedEndpoint = endpoint.replace(/-/g, '_'); // Normalize dashes for handler lookup if needed
    
      // Log endpoint for debugging
      serverInstance?.sendLoggingMessage({
        level: "info",
        data: `NASA Endpoint: ${endpoint} (Normalized: ${normalizedEndpoint})`,
      });
    
      try {
        // Dynamic import for NASA handlers using the original slash format path
        const handlerModule = await import(`./handlers/nasa/${endpoint}.js`);
        serverInstance?.sendLoggingMessage({
          level: "info",
          data: `Successfully imported handler module for: ./handlers/nasa/${endpoint}.js`,
        });
    
        // Try different potential handler function names
        const handlerFunctionName = `nasa${endpoint.charAt(0).toUpperCase() + endpoint.slice(1).replace(/-/g, '_')}Handler`; // e.g. nasaMars_roverHandler
        const simpleHandlerName = `${endpoint.replace(/-/g, '_')}Handler`; // e.g. mars_roverHandler
    
        const handlerFunction = handlerModule.default || 
                               handlerModule[handlerFunctionName] || 
                               handlerModule[simpleHandlerName];
    
        if (typeof handlerFunction === 'function') {
          serverInstance?.sendLoggingMessage({
            level: "info",
            data: `Executing handler function for ${endpoint}`,
          });
          return await handlerFunction(args);
        } else {
          serverInstance?.sendLoggingMessage({
            level: "info",
            data: `No handler function found in module: ${JSON.stringify(Object.keys(handlerModule))}`,
          });
          throw new Error(`No handler function found for NASA endpoint: ${normalizedEndpoint}`);
        }
      } catch (importError) {
        throw new Error(`Failed to import handler for NASA endpoint: ${normalizedEndpoint}. Error: ${importError instanceof Error ? importError.message : String(importError)}`);
      }
Behavior2/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 but only states it provides 'information' without detailing aspects like rate limits, authentication needs, response format, or whether it's a read-only operation. It lacks critical behavioral traits needed for safe and effective use.

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 directly states the tool's general purpose. It is front-loaded and wastes no words, though it could be more specific to improve clarity without sacrificing conciseness.

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?

Given the tool has 3 parameters, no annotations, and no output schema, the description is incomplete. It does not explain the return values, how to interpret results, or the tool's behavior in different scenarios (e.g., using asteroid_id with dates), leaving significant gaps for an AI agent to use it correctly.

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 parameters (start_date, end_date, asteroid_id) with clear descriptions. The description does not add any meaning beyond this, such as explaining relationships between parameters (e.g., that asteroid_id can be used optionally for specific lookups) or additional constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool provides 'information about asteroids' using the 'Near Earth Object Web Service', which gives a general purpose but lacks specificity about what kind of information (e.g., search results, details) or the exact operation (e.g., search, lookup). It distinguishes from some siblings like 'nasa_apod' but not clearly from other asteroid-related tools like 'jpl_sbdb' or 'jpl_sentry'.

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 on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, leaving it unclear how it differs from sibling tools such as 'jpl_sbdb' (which might also handle asteroid data) or when date ranges versus asteroid IDs are appropriate.

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/ProgramComputer/NASA-MCP-server'

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