PUBLIC DATA · PREVIEW
Use OrbitSmith with Your AI
Use your own AI to explore orbital records, calculate positions, find observation candidates or check and compare radio-link calculations.
No OrbitSmith account or API key is needed. OrbitSmith does not call an AI model; your AI provider's terms and fees still apply.
What would you like to know?
Choose a goal for its instructions and example question. Items 1–3 need an AI with web access. Items 4–6 need browser controls; items 5–6 also need you to supply and confirm design inputs.
Understand one object
Requires an AI that can read web pages
Learn the recorded name, classification and launch date when available, plus orbit height and time per orbit. Your AI explains the numbers with sources.
Example question“Use OrbitSmith to explain ADRAS-J’s record.”
How to use it
Copy the example question below into an AI chat with web access, then replace the example object names before sending. If several objects match, choose a NORAD ID when asked.
ADRAS-J and HST are examples. Replace the name in the question with a catalog name or NORAD ID you want to investigate. Keep the directory URL unchanged; you do not need to find an individual data URL.
Open the public object directory
View the full example question
Start at the following OrbitSmith public directory and follow its links to retrieve the data for “adras J”. https://orbitsmith.net/data/orbitsmith/catalog/directory/index.html Briefly explain the name, NORAD ID, launch date if recorded, and data timestamps in plain English, with sources. If there are multiple candidates, let me choose. Do not add general knowledge. If retrieval fails, tell me where it stopped. Also report the recorded classification, perigee and apogee altitudes, and period when available, with units and a brief explanation. Distinguish the snapshot time from the orbital reference time, retain warnings, and leave missing values unknown. These records do not show current position or operational status.
Scope and limits
All objects listed in OrbitSmith's public catalog are searchable, not just the examples. Available fields vary by object, and AI retrieval may fail.
Follow up · Ask about another object
After the first answer, you can continue in the same chat. For example, ask about HST instead.
Using the same OrbitSmith directory, now look up “HST” and explain the same fields in plain English, with sources and dates. https://orbitsmith.net/data/orbitsmith/catalog/directory/index.html Let me choose if there are multiple candidates. Do not add general knowledge; if retrieval fails, tell me where it stopped.
Compare two objects
Requires an AI that can read web pages
If your AI retrieves both records, ask it to compare their shared fields. This does not calculate how close the objects pass.
Example question“How do ADRAS-J and HST differ in orbit height and period?”
How to use it
Copy the example question below into an AI chat with web access, then replace the example object names before sending. If several objects match, choose a NORAD ID when asked.
View the full example question
Read the guide below, then start at the OrbitSmith public directory and follow its links to retrieve the actual records for both “ADRAS-J” and “HST”. https://orbitsmith.net/llms.txt https://orbitsmith.net/data/orbitsmith/catalog/directory/index.html If either name fits more than one object, show the candidates, stop, and ask me to choose a NORAD ID. Check that the NORAD ID in each record you retrieved is the object it is meant to be; never use a sample or example object's record instead. Then put the two records side by side, briefly: name, NORAD ID, object type, launch date if supplied, perigee and apogee altitudes in km, inclination in degrees, period in minutes. Keep the names, IDs and values as OrbitSmith returned them. State the data snapshot time, the response generation time (generated_at) returned by OrbitSmith, and the orbital element epoch (and the TLE epoch when it differs) separately, and keep any epoch-mismatch warning OrbitSmith returned. Do not present the two records as where the objects are at the same moment. Leave missing values unknown; if a field is supplied for only one object, show unknown for the other and give no difference for that field. You may subtract the same field between the two objects (for example apogee minus apogee) if you say you calculated it and give the unit. Do not estimate the distance between the objects, how close they pass, collision or reentry risk, safety, or which one is better. Cite each record URL and its upstream sources. Explain briefly in plain English. Do not fill anything in from general knowledge. If either record cannot be retrieved, tell me which one and where it stopped, and do not present the comparison as complete.
Scope and limits
Shows how two records differ in recorded orbit height, orbit tilt and time per orbit. ADRAS-J and HST are only examples: replace both with any two catalog names or NORAD IDs. It does not work out the distance between the objects or any safety judgement.
Calculate a position at a chosen time
Requires an AI that can read web pages
Ask where an object is calculated to be at a date and time you specify: latitude, longitude and height. This needs supported orbital data; it is not an observed live location or a pass prediction.
Example question“Where is HST calculated to be at the date and time I specify?”
How to use it
Copy the example question to an AI with web access, replacing HST if needed. It will ask for the date, time and time zone before requesting a calculation.
View the full example question
Use OrbitSmith to calculate HST's position at a time I choose. First ask me for the full date, time and time zone; do not choose a time for me. Read this guide and follow its position-calculation instructions: https://orbitsmith.net/llms.txt Find the object in the public directory below. If there are several candidates, stop and let me choose a NORAD ID. https://orbitsmith.net/data/orbitsmith/catalog/directory/index.html After the object and time are agreed, fetch the position calculation URL for that NORAD ID and UTC. Check the returned ID and time. Briefly explain the latitude, longitude and WGS84 ellipsoid height in plain English, with the orbital data's reference time, sources and warnings. This is a calculated position at the requested time, not an observed current location or a pass prediction. If retrieval fails or no result is returned, explain where it stopped; do not substitute another object, time or calculation.
Scope and limits
HST is only an example; replace it with a catalog name or NORAD ID. First tell your AI the full date, time and time zone. It prepares the calculation URL; you do not need to edit one. Calculations are limited to 7 days before or after the orbital data's reference time, not today. Missing or inconsistent data stops the calculation. This limit does not guarantee accuracy.
Find observation candidates from your city
Requires an AI that can operate a browser
Your AI operates the existing Passes page and explains the calculated candidate times, directions and maximum elevation for your city.
Example question“Find ISS observation candidates from Tokyo tonight, with times and directions.”
How to use it
Use an AI with browser controls and permission to operate Passes. Copy the example question below, then tell it your city, period and time zone. Merely reading a URL or choosing a model does not enable browser controls. Before sending the example, check that your browser integration is enabled, signed in and connected. If it cannot read the page, check the connection before starting a calculation.
View the full example question
Use browser controls to operate OrbitSmith Passes, not just fetch the page text: https://orbitsmith.net/passes First ask me for the city, period (Tonight, Next 24h or Next 3 days) and display time zone. Confirm the actual dates and interval for that choice. Do not reuse a saved location, obtain my current location or choose another period without asking. Search for the city on the page and let me choose if the place name is ambiguous. Let Passes calculate, then select ISS (NORAD ID 25544) and open its details. Report the selected coordinates, period and filters. Stop if you cannot operate the browser, the calculation fails, or the requested conditions are unsupported; do not substitute another object, time or your own calculation. Briefly explain the displayed pass candidates in plain English: date and time zone, start, peak and end times, directions and maximum elevation. Preserve warnings and cite the page and its stated sources. If available, distinguish the result generation time from the TLE epoch; otherwise say they are unavailable. The page assumes WGS84 ellipsoid height 0 m and displays times in the device time zone. Read only relevant result fields, not the entire large JSON. No candidate under the selected filters does not mean no geometric pass. Brightness is not assessed and visibility is not guaranteed; do not infer operational safety.
Scope and limits
Use the page's Tonight, Next 24h or Next 3 days options and its listed candidates. This does not cover arbitrary dates or every catalog object. Brightness is not assessed, so a candidate is not a promise of a naked-eye sighting.
ISS is an example. Before using another object, check that it is included in Passes. Your AI should ask for the city and period rather than use a saved location.
Check a satellite radio link's margin
Requires browser controls and your confirmed design inputs
Work through your design in Mission Engineering Workbench. Your AI helps gather the inputs, uses the page's calculations and explains how the radio-link margin compares with your requirement at nearer and farther distances. It cannot find this margin from a satellite name alone.
Example question“Use OrbitSmith to check the radio-link margin for my design. First help me identify the inputs I need.”
How to use it
Check that your AI's browser integration is enabled, signed in and connected. Use the example below to begin with your own design or an explicitly agreed educational scenario. You do not need every number ready at the start; your AI can first list what is missing.
- Choose the design, orbit, ground station and time interval. Review the source, units and assumptions of the inputs; do not silently adopt saved or default values.
- Use the page's sequence: Visibility → Ground-station geometry and distance → Link budget. Confirm the requested inputs yourself before each calculation.
- Read the calculated distances, best/worst margins and your required margin together. Keep any missing information and warnings alongside the result.
You will need frequency, transmit power, both antenna gains, receiver noise temperature, data rate, required signal quality (Eb/N0), required margin and losses. Your AI should ask about unknowns—not invent equipment specifications or enter zero.
View the full example question
Use browser controls to operate OrbitSmith Mission Engineering Workbench and help me check the radio-link margin for my design: https://orbitsmith.net/mission-engineering?group=ground_comms&module=link_budget First ask whether this is my actual design or an educational scenario, and which concept to use. Before editing, confirm what may be changed; do not overwrite a saved design or adopt default values without my permission. Ask for the orbit and its source/reference time, full dates/time zone (convert to UTC with me), ground station, coordinates, WGS84 ellipsoid height and minimum elevation. Do not obtain my location. Treat any planning orbit or assumed station as an assumption, not an observed satellite record or verified station specification. Follow the page's prerequisites in the same concept and revision: Visibility → Ground-station geometry and distance → Link budget. Ask for frequency, transmit power, transmit/receive antenna gains, receiver noise temperature, data rate, required Eb/N0, required margin and all nine losses, with units and sources or explicit assumptions. If a value is missing, stop and list what is needed; do not replace it with zero or invent a specification. Only use an educational assumption after I explicitly agree to it. Leave human input-confirmation checkboxes to me; do not mark them confirmed on my behalf. Once I have confirmed the inputs, run each calculation on the page. Read only relevant displayed results. Briefly explain in plain English the inputs used, near/far distances, best/worst radio-link margins in dB and how they compare with my required margin. Use only valid results for the selected concept and revision, and distinguish detailed results from the simplified check. Cite OrbitSmith, the page URL and sources actually shown. Distinguish the result generation time from the orbital reference time when available; otherwise say unknown. Preserve missing information, assumptions and warnings. If browser operation, inputs or prerequisites are unavailable, or calculation fails, stop and explain where; do not substitute a different design, orbit, time or your own calculation. This is an educational/initial design calculation, not a guarantee of actual communication, frequency authorization, ground-station availability, booking or operational safety. Do not infer transferable MB or treat geometric visibility time as usable transmission time. Do not upload or send my design to another service.
Scope and limits
This explains a calculation under your stated assumptions—not a guarantee of actual communication. Frequency authorization, ground-station service availability and booking remain separate checks. It does not calculate how many MB you can send, and geometric visibility is not usable transmission time.
The browser workflow has been checked with one educational case. Try it with your AI and review the inputs and results; this is not verification for every AI or real mission.
Compare a radio-link input change
Requires browser controls and your confirmed design inputs
Use the same Workbench design to compare its radio-link margin before and after changing one communication input. Your AI keeps a record of the earlier result, operates the existing calculation, and explains the difference.
Example question“What happens to the radio-link margin if I lower the data rate? Help me choose the before and after values first.”
How to use it
- Choose the concept and one communication input to change. Agree on the before/after values, units and all conditions that will stay fixed. The question above is an example, not a preset design.
- Obtain a valid detailed result using the steps in item 5. Before editing, keep the relevant inputs, results, sources and warnings in this conversation: editing can remove the old result from the page.
- Change only the agreed input, confirm the inputs yourself again and recalculate on the page. Compare the before/after margins with the requirement, keeping simplified results separate.
Workbench does not automatically keep a before/after history of all detailed results. Avoid unnecessary reloads or concept switches during the comparison; do not assume that switching back restores edited values.
Check a satellite radio link's margin · Open Link budget in Workbench
View the full example question
Use browser controls to operate OrbitSmith Mission Engineering Workbench and compare the radio-link margin before and after changing one communication input: https://orbitsmith.net/mission-engineering?group=ground_comms&module=link_budget First ask which concept to use, whether it is an actual design or an educational scenario, what I want to change, and the before/after values and units. Lowering the data rate is only an example: do not choose values for me. Confirm permission to edit the chosen Workbench input; do not overwrite a saved design without permission or change the Guided concept. Keep the other inputs fixed. Do not obtain my location. Before calculating, confirm the orbit, its source/reference time, full UTC interval (confirm any time-zone conversion with me), station coordinates, WGS84 ellipsoid height and minimum elevation. Also confirm frequency, transmit power, both antenna gains, receiver noise temperature, data rate, required Eb/N0, required margin and all nine losses, with units and sources or explicitly agreed assumptions. Fictional or assumed values are not observed satellite data or verified equipment specifications. Stop if inputs are missing; do not invent them or replace them with zero. Leave human input-confirmation checkboxes to me. Before editing, obtain valid detailed results for the selected concept and revision, following the page's Visibility → Ground-station geometry and distance → Link budget prerequisites. I will confirm the inputs before you run each calculation. Keep the before inputs, distances, best/worst margins and required margin in this conversation, with units, concept/revision when visible, sources, warnings and assumptions. Editing can remove the earlier result; do not claim the app automatically stores its history. Change only the agreed Workbench input. Follow the page's invalidation and prerequisite requirements, wait for my confirmation again and then recalculate. Do not mark checkboxes on my behalf. Avoid unnecessary reloads or concept switches. Check that the after result matches the new input and selected concept/revision; do not reuse an invalid old result. Briefly compare the before/after displayed results in plain English. Label any subtraction as your arithmetic, with units. Keep the simplified check separate from detailed results and distinguish result generation times from the orbital reference time; unreadable values remain unknown. Cite OrbitSmith, the page URL and displayed sources. Retain warnings, assumptions and unassessed items. A model-derived distance under a fictional orbit is not measured distance. Do not infer effects on power consumption, cost, schedule, transferable MB, actual communication, station availability, operational safety or the best overall mission. If browser controls, inputs, previous results or the calculation are unavailable, stop and explain where; do not substitute a different design or your own calculation. Do not upload or send my design to another service. This is for education and initial design exploration, not an operational guarantee.
Scope and limits
This initially covers one communication-input change, not a whole-design impact analysis. It does not assess power consumption, cost, schedule, transferable MB, actual communication or which mission is best.
One educational data-rate-change case has been checked with browser controls. This is not verification of every input change, AI or real mission.
Check these points in any AI answer
It may use an older response
An AI may reuse older data or fail to open a URL. A successful fetch does not guarantee the latest snapshot. Check the actual publication and orbital reference dates, not only “hours ago”. If it requests a URL again, paste that URL; missing values must remain unknown.
Some orbital timestamps disagree
Some records report different reference times in the orbital fields and the TLE (data used for orbit calculations). OrbitSmith warns about this; it has not reconciled those times. Do not use a warned-about record unchanged for position or pass predictions.
An AI can add unsupported claims
Ask it to use only returned fields, distinguish missing values, and cite the sources. A catalog classification does not tell you whether an object is operating.
For learning and initial understanding
These tools are for education, research and initial understanding, not satellite operations, collision avoidance, ground safety or official warnings.
For developers · Public data and optional tools
The examples above need no MCP setup. Object lookup and position calculations have read-only JSON responses with sources and warnings. Passes, Link budget and input-change comparisons above use browser controls; no pass or radio-link API is provided here.
AI access guide
llms.txtSearch by name or ID
Returns up to 10 candidates; a unique match includes the object record when available. Example:
/ai/objects/resolve?query=ISS&limit=5Read one object
Direct lookup for a selected NORAD ID. The questions above start from the public directory; this is an alternative for developers. Example:
/ai/objects/25544Position calculation · GET
Use a selected NORAD ID (1–99999) and URL-encoded absolute UTC ending in Z. Only the at parameter is accepted. This URL is a template, not a ready-to-open example:
https://orbitsmith.net/ai/positions/{NORAD_ID}?at={UTC}Position calculations allow 6 requests per 10 seconds per source IP and Cloudflare location, then block for 10 seconds. This is separate from lookup limits. Shared AI connections may share the limit; on HTTP 429, stop rather than repeatedly retrying. No API key or AI-model call is needed.
Other public datasets
The manifest lists available snapshots, including statistics and reentry summaries, with their individual limitations.
/data/orbitsmith/manifest.jsonThe public lookup is read-only and keyless, with a rate limit of 30 requests per minute per connection source. It does not trigger new Space-Track/CelesTrak requests or paid AI calls. Cite OrbitSmith and the upstream sources named in each response.
Optional · Repo-local MCP bridge
For developers who already have access to the OrbitSmith repository. This is a local helper, not a hosted service or a requirement for the examples. Replace the repository path below with your own.
Claude Code
claude mcp add orbitsmith-public -- node /path/to/orbitsmith/scripts/public-mcp-bridge/server.js
Codex
[mcp_servers.orbitsmith-public] command = "node" args = ["/path/to/orbitsmith/scripts/public-mcp-bridge/server.js"]
Questions or feedback?
Tell us what was unclear or which answer looked wrong. Contact OrbitSmith