Test locally

The two endpoints to point at

For routine development, point at the anonymous endpoint. Switch to the authenticated one when you outgrow 50 calls per day or want per-account attribution.

• https://mcp.lumin.guru/mcp for anonymous (50/day per IP) or with an API key in the Authorization header.
• https://mcp.lumin.guru/mcp/auth for OAuth 2.1, 100/day on Free, more on paid tiers.

Use MCP Inspector for interactive debugging

The official @modelcontextprotocol/inspector CLI gives you a UI to call any tool with structured inputs and inspect the full response. Best way to learn the tool surface.

npx @modelcontextprotocol/inspector https://mcp.lumin.guru/mcp

curl recipes for scripted runs

List tools to confirm the connection works:

curl -X POST https://mcp.lumin.guru/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' \
  | jq '.result.tools | length'

Call a single tool with realistic birth data:

curl -X POST https://mcp.lumin.guru/mcp \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "tools/call",
    "params": {
      "name": "get_full_chart",
      "arguments": {
        "birth_datetime": "1992-08-14T04:32:00",
        "latitude": 6.927,
        "longitude": 79.861,
        "utc_offset_minutes": 330,
        "ayanamsa": "kp"
      }
    }
  }' | jq '.result'

Pin canonical test profiles

Hard-code two or three birth profiles in your test fixtures and reuse them across runs. The KP results are deterministic, so the same input always returns the same output. That makes regressions in your client easy to spot.

// fixtures/profiles.ts
export const PROFILE_A = {
  birth_datetime: "1992-08-14T04:32:00",
  latitude: 6.927,
  longitude: 79.861,
  utc_offset_minutes: 330,
  ayanamsa: "kp" as const,
};

export const PROFILE_B = {
  birth_datetime: "1985-01-23T09:15:00",
  latitude: 28.6139,
  longitude: 77.2090,
  utc_offset_minutes: 330,
  ayanamsa: "kp" as const,
};

Watch out for time-dependent tools

A small group of tools take the current moment as input and therefore produce different output on every call. Do not use these in snapshot tests:

• get_ruling_planets computes for "now".
• get_moon_transit changes every 2-3 hours as the Moon sub advances.
• get_smart_current_dasha reflects the current running period.
• find_auspicious_time and get_muhurta_advanced scan forward from now by default.

For these, either pass an explicit query_datetime / scan_start argument so the result is reproducible, or accept that the response varies and assert only on shape.

Avoid burning the daily quota during dev

• Cache responses in memory or disk while iterating on prompt logic. Birth-data tools are pure functions of their inputs.
• A complete reading uses 25-40 calls; with 50/day on the anonymous tier, two readings burn the budget. Get an API key early.
• Failed calls (4xx, 5xx) do not count, so retries during debugging are free.
• The meter resets at 00:00 UTC.

Get an API key

Sign in at app.lumin.guru/developer and generate a key. Add it as a Bearer header on every call:

Authorization: Bearer mcp_yourkey...