NeoWs - (Near Earth Object Web Service)

{
  "service_type": "platform",
  "base_url": "https://neowsapp.com",
  "auth_method": "api_key",
  "auth_config": {
    "notes": "NASA's Near Earth Object Web Service (NeoWs) is part of NASA's Open APIs and typically requires a NASA API key (api_key query parameter). Keys are free and obtained from api.nasa.gov. The neowsapp.com domain appears to be a related/third-party frontend; the canonical API is at https://api.nasa.gov/neo/."
  },
  "endpoints": [
    {
      "name": "NeoWs Feed",
      "method": "GET",
      "path": "/neo/rest/v1/feed",
      "description": "Retrieve a list of near earth objects based on closest approach date range."
    },
    {
      "name": "NeoWs Lookup",
      "method": "GET",
      "path": "/neo/rest/v1/neo/{asteroid_id}",
      "description": "Retrieve details for a specific asteroid by its SPK-ID or JPL ID."
    },
    {
      "name": "NeoWs Browse",
      "method": "GET",
      "path": "/neo/rest/v1/neo/browse",
      "description": "Browse the overall list of near earth objects."
    }
  ],
  "pricing_model": {
    "type": "free",
    "details": {
      "note": "NASA Open APIs including NeoWs are free to use with a registered API key. Rate limits apply at the API gateway level (e.g., hourly/daily request caps for api.nasa.gov keys)."
    }
  },
  "rate_limits": {
    "default": "Standard NASA API key limits apply (commonly 1,000 requests per hour for api.nasa.gov keys; verify current policy).",
    "notes": "Rate limits are enforced at api.nasa.gov, not necessarily at neowsapp.com."
  },
  "capabilities": [
    "Near Earth Object (NEO) data retrieval",
    "Asteroid close-approach tracking",
    "Date-range queries for NEO feed",
    "Individual asteroid detail lookup",
    "Browsing full NEO catalog",
    "Data sourced from NASA JPL Asteroid Team",
    "Powers third-party apps such as AsteroidTracker",
    "REST/JSON web service",
    "Suitable for astronomy, education, and space-safety applications"
  ],
  "raw_analysis": "NeoWs (Near Earth Object Web Service) is a data platform that provides access to NASA's near earth object datasets, originating from the NASA JPL Asteroid team. The service is publicly documented as part of NASA's Open APIs ecosystem at api.nasa.gov, where it is exposed as a REST/JSON API consisting of three primary endpoints: feed (date-range queries), lookup (individual asteroid by ID), and browse (full catalog). Authentication is via a free NASA API key passed as the api_key query parameter. The neowsapp.com URL appears to be a related web frontend or a mirror/third-party deployment; the canonical, documented API base is https://api.nasa.gov/neo/rest/v1/. Because the service is backed by NASA Open APIs, it is free to use, with standard api.nasa.gov rate limits (commonly on the order of 1,000 requests/hour for registered keys). The platform is mature, well-known in the astronomy and space community, and is used to power applications such as AsteroidTracker. Its primary audience includes developers, researchers, educators, and space enthusiasts building applications around asteroid close approaches and planetary defense awareness. Integration surface: standard HTTP GET requests returning JSON, easily consumed by web, mobile, and data-analysis tooling."
}

1/3 tests passed

{
  "overall": 72,
  "dimensions": {
    "token_efficiency": 9.0,
    "first_try_success": 7.5,
    "response_parseability": 9.0,
    "error_clarity": 6.5,
    "doc_quality": 7.5,
    "auth_simplicity": 7.0,
    "latency": 9.5,
    "consistency": 8.0
  },
  "pricing_normalized": {
    "model": "free",
    "notes": "Free with registered NASA API key; gateway-level hourly/daily rate limits apply. Predictable cost (zero), but throttling behavior is not fully specified."
  },
  "issues": [
    "robots.txt and llms.txt return 401 (Full authentication required), which is unusual for these public-facing resource endpoints and suggests a gateway config that blocks unauthenticated discovery paths.",
    "Rate limit specifics (exact hourly/daily caps) are not clearly documented at the API level, making agent throughput planning harder.",
    "No llms.txt or agent-oriented discovery file, reducing machine-first onboarding clarity.",
    "Authentication requires email-based API key signup, which is a human-gated flow and slows agent-driven provisioning."
  ],
  "recommendations": [
    "Expose robots.txt and a public llms.txt without auth so agents can discover capabilities and usage guidance programmatically.",
    "Publish concrete rate-limit numbers (per hour/day) and 429 response formats in the docs so agents can implement backoff correctly.",
    "Provide OpenAPI/Swagger JSON (already partially present via swagger-ui) at a stable unauthenticated URL for schema-driven client generation.",
    "Consider a demo/demo-key mode for low-volume exploration so agents can test before provisioning a real key.",
    "Document error codes and payload shapes explicitly in the help docs to improve error_clarity."
  ]
}