This server gives read-only access to ASTRO's hosted crypto market intelligence through four tools — no trades, accounts, or API keys involved.
astro_get_started — returns setup instructions; makes no external request and creates no account.
astro_signal — reads the composite score, market regime, component summary, and source metadata.
astro_context — reads weighted component explanations, adjustment traces, rankings/breadth, and available prediction-market, macro, sentiment, and liquidity context.
astro_basket — reads the ten supported assets (BTC, ETH, SOL, ADA, DOGE, ARB, OP, LINK, POL, DOT) with quotes, funding, volatility, SMA/ATR, strategy assessments, gates, and freshness flags.
All tools are marked non-destructive, idempotent, and open-world; none place orders, expose positions, or touch balances.
In 0.7.0 no signup, key, or trial activation is required; each resource is cached locally for up to 15 minutes.
Runs over local stdio in any MCP-compatible client (Python 3.10+), including headless containers.
Outputs are scores and heuristics, not calibrated probabilities; missing or stale inputs stay visible.
This repository contains the runnable Python/stdio MCP server implementation, not just an API specification or client example. The server runs locally in an MCP-compatible client and retrieves intelligence from ASTRO's hosted HTTPS API.
MCP tool | Function |
| Setup instructions; no account creation or external request |
| Composite, market regime, component summary, and source metadata |
| Component explanations and available prediction-market, macro, sentiment, and liquidity context |
| Ten-asset analysis including funding, volatility, rankings, strategy assessments, and freshness indicators |
The tools expose intelligence and decision support, not trade execution, private positions, or account balances. Missing or stale inputs remain visible; scores are not calibrated winning probabilities.
Related MCP server: carbon-cashmere-mcp
Python 3.10+ is required. No PyPI publication is implied by these commands.
git clone https://github.com/jarvisways-cyber/astro-starbase-crypto-api.git
cd astro-starbase-crypto-api
python -m venv .venvWindows:
.\.venv\Scripts\python.exe -m pip install ".[mcp]"
.\.venv\Scripts\python.exe scripts/check_mcp_stdio.pymacOS/Linux (use python3 above if needed):
.venv/bin/python -m pip install '.[mcp]'
.venv/bin/python scripts/check_mcp_stdio.pyThe check starts a real stdio subprocess, initializes MCP, lists all four tools, and calls setup guidance. It does not activate a trial or require a key.
Configure your AI client's MCP server with the absolute path to .venv/Scripts/astro-mcp.exe on Windows or .venv/bin/astro-mcp on macOS/Linux, and arguments ["serve"]. The transport is stdio, not HTTP. Full client setup and access behavior.
MCP 0.7.0 provides the complete public intelligence responses without signup, API keys, trial activation, payment details, or a credential store. It works in headless containers as well as desktop clients. Call any intelligence tool immediately after connecting. Existing saved credentials and account records are untouched.
Run python scripts/check_mcp_live.py in the installed environment to test all three tools against the live public service. This test supplies no credentials and requires all ten assets in the basket. It creates no account and sends no email.
AI client <--- MCP stdio ---> this repository's Python server
|
+--- HTTPS ---> ASTRO intelligence/account APIAll MCP protocol handling, tool definitions, local caching, trial recovery, and credential-store integration are present in this repository. The market collector and private paper-execution engine run separately on the VPS and are not required to install or inspect this MCP server. This connector requires the hosted service for live intelligence; it does not collect market data independently.
https://64.227.50.56/mcp is a setup webpage, not a remote MCP protocol endpoint. The same repository also includes the website, API integration documentation, and Python SDK described below.
ASTRO combines market inputs into regime assessments and asset-level scores. Its API exposes the components behind those assessments—not just a final number.
Nine weighted composite components: fear/greed, market structure, funding, liquidity, macro, on-chain, options, narrative, and congressional-activity scores.
Calculation explanations: active weights, bear-regime inversions, component contributions, and subsequent adjustments.
Cross-asset context: 24-hour changes, volume, rankings, and BTC-relative breadth, with coverage and freshness information.
Supporting intelligence: momentum/sentiment axes, per-asset funding, open interest, stablecoin supply, macro prediction-market context, SMA, ATR, and candle-pattern details where available.
Decision context: per-asset scores, strategy assessments, dimension checks, and veto reasons—not executed customer orders.
Supported assets: BTC · ETH · SOL · ADA · DOGE · ARB · OP · LINK · POL · DOT
Use https://64.227.50.56, ASTRO's primary HTTPS address.
MCP 0.7.0 uses this VPS for credential-free intelligence. The previous Vercel address remains available temporarily for compatibility and rollback; new integrations should use the primary address. This is the same ASTRO service, not a separate plan. Existing keys and trial deadlines remain unchanged.
Route | Response |
| Published composite, regime, component summary, BTC quote and observation metadata |
| Weighted explanations, adjustment trace, rankings/breadth and supporting intelligence |
| Ten-asset scan: prices, score velocity, SMA, funding, ATR, strategy assessments and explanations |
Authenticate with the X-API-Key header. Keep your key server-side, out of
URLs, public frontends, repositories and screenshots.
Polling: one request per resource per key every 15 minutes. Fetch signal, context and basket once each in the same cycle, then cache them. This is an intelligence service, not a tick-by-tick streaming product.
Python 3.10+; no third-party packages needed:
python examples/api_snapshot.pyThe example asks for your key in a local masked prompt, fetches all three routes and prints a market summary. It never places trades or saves your key. See the API guide for fields, status handling and interpretation.
The backend now runs on a VPS rather than a laptop connection. Collection, API delivery, customer-key synchronization and internal paper execution are separate supervised services.
Verified at deployment:
One customer key fetched all three public routes successfully.
Missing/invalid keys were rejected; all ten assets had quote data.
Component contributions reconciled to the base score.
Collection continued after the paper worker stopped.
API restart preserved history; release and state rollback checkpoints were saved.
This dated verification is not an uptime SLA or profitability claim.
Composite and ascendancy are scores, not calibrated probabilities of profit.
Velocity measures changes in the asset's intelligence score, not price returns.
Collection time does not establish freshness of every upstream source. Fallbacks may be present; check quality, missingness and stale fields.
Strategy confidence is a heuristic, not a winning-probability estimate.
An OPEN analytical gate is not an order or a promise of execution.
Customers can integrate ASTRO into their own software. These endpoints do not require an ASTRO bot installation and do not execute customer trades.
The internal bot remains paper-only. Module 8 evaluates candidate signal weights separately; it does not automatically replace published weights. Hive and broader autonomous strategy improvement remain development work.
Want a local ASTRO paper-trading client and another way to support the project? See the Trade Bot page. Qualifying founding-year purchases include API access without another subscription charge while ASTRO operates the service, subject to published limits, plus lifetime consumer-software updates. See cohort dates and terms.
The current v3.2 package is paper-only and includes the reliability improvements. Read the release limitations and purchase distinction before treating it as a validated trading product. The API does not require it.
The client in this repository now uses the three hosted routes. Install from a
local checkout with python -m pip install ., then run an example that asks for
your key in a masked prompt. This update has not been published to PyPI.
ASTRO.snapshot() returns raw signal/context/basket responses. Typed helpers
reuse a 900-second per-resource cache; they preserve missing scores as null.
See SDK behavior and migration.
This repository contains ASTRO's MCP server implementation, Python SDK, website, integration documentation, and OpenAPI specification. The separate astro-oracle repository is a project archive. The private hosted collector and paper-execution runtime are separate from the MCP server source linked above.
For new integrations, use the API guide, the dependency-free snapshot example, or the updated source SDK. The OpenAPI specification documents the three hosted resources and permits additive intelligence fields.
Architecture and research lineage explains the wider project. The previous Starbase overview preserves its original design discussion and historical research claims without presenting them as current performance evidence or deployment instructions.
The existing MIT license is retained for this API repository. The SDK has not been published to PyPI. The separate paid consumer release is described in consumer release notes.
The current connector uses public intelligence routes, with no signup or trial. Versions 0.6.0 and earlier used anonymous trial activation; upgrade to 0.7.0 for credential-free access. The server may reuse calculations for up to 30 seconds; the connector caches each resource for up to 15 minutes. Source timestamps and stale/missing flags remain unchanged. Availability and service capacity limits apply; no unlimited-uptime promise is made.
Read ten-asset rankings, funding, volatility, strategy assessments and freshness.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety and idempotency profile is fully covered. The description adds only that the read returns a fixed ten-asset set with a freshness indicator, which is modest extra context about staleness but nothing about rate limits, auth, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler, though the comma-separated noun list is somewhat flat and would benefit from grouping the data categories more clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining what comes back, and it partially does by listing the data categories. However, terms like 'strategy assessments' and 'freshness' are undefined, and the fixed 'ten-asset' scope is never explained, leaving the agent with an incomplete picture of the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline of 4 applies; there is no parameter surface the description needs to explain. The description does not need to add syntax details since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description enumerates what the tool reads (ten-asset rankings, funding, volatility, strategy assessments, freshness), which is more informative than the opaque name 'astro_basket'. However, it is a noun dump with no clear verb-resource framing and no differentiation from siblings like astro_signal or astro_context, so an agent cannot tell when this basket view is the right one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of the sibling tools (astro_get_started, astro_signal, astro_context) that could serve as alternatives. The agent must infer usage purely from the data categories listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read market context, score explanations and available prediction-market inputs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety behavior is covered. The description adds only a hint about returned content ('available prediction-market inputs') and says nothing about scope, freshness, or openWorld behavior despite openWorldHint being set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with no filler, front-loaded with the verb. It is brief rather than padded, though the brevity comes at the cost of substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-argument read tool with no output schema, the description is the only signal about what comes back, and it is thin. 'Score explanations' is unexplained and there is no mention of the response shape, leaving the agent with an incomplete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema coverage is 100%, so there is nothing for the description to disambiguate. Baseline 4 applies for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a resource (market context, prediction-market inputs) and a verb (read), but 'score explanations' is ambiguous and the overall purpose stays fuzzy. It does nothing to distinguish itself from siblings like astro_signal or astro_basket, so an agent must guess which context tool to call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus the three sibling tools, no prerequisites, and no exclusions. The agent is left to infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain public access; no signup, credentials or trial activation needed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful auth context by stating no signup, credentials, or trial activation are needed, but it does not describe output format or any other runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler. It is front-loaded with the intended action ('Explain public access'), though the terse phrasing leaves the action somewhat ambiguous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, non-destructive informational tool with no output schema, the description covers access requirements but not what the tool actually returns or how it should be used in an agent workflow. It is minimally adequate but misses useful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there are no parameter semantics for the description to clarify. The schema is an empty object, and the baseline for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Explain public access' and adds an access constraint, but it does not clearly state what the tool returns or how it differs from siblings astro_signal, astro_context, or astro_basket. The purpose is vaguely inferable as an onboarding or public-access explanation tool, but not specific enough for confident selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The statement about no signup or credentials gives a usage condition only indirectly, but it does not say when this tool is preferred over the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read composite, market regime, component signals and source timestamps.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered without the description. The description adds some value by naming the returned payload parts (including source timestamps, implying freshness metadata), but with no output schema it stops short of explaining the shape or meaning of those values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. It is efficient, though extremely terse given the absence of an output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and annotations covering safety, the main gap is the return payload. The description lists four returned data categories but, in the absence of an output schema, does not explain what 'composite' or 'market regime' contain or how timestamps should be interpreted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No syntax or argument guidance is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a verb (Read) and enumerates the resources returned (composite, market regime, component signals, source timestamps), which is more than a restatement of the name. However, it never says what a 'signal' is conceptually or how this differs from siblings astro_context or astro_basket, leaving an agent to guess which one to call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no exclusions, and no reference to the sibling tools. An agent has no stated condition for choosing astro_signal over astro_context or astro_basket.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.6.0astro_basketastro_contextastro_get_startedastro_signalScored across 4 tools
The three read-oriented tools (signal, context, basket) target different data payloads, but signal and context both concern market analysis and could be conflated by an agent seeking regime or explanation data. get_started is clearly distinct as an onboarding tool. Overall mostly distinct with minor overlap.
All tools use the astro_ prefix and snake_case, providing a predictable namespace. The only deviation is the verb phrase get_started among noun-based resource tools, but consistency remains high.
Four tools is well within the ideal range and each covers a distinct area: onboarding, signals, context, and basket. No tool appears redundant, and the set is appropriately scoped for a specialized market intelligence server.
The read-only surface covers onboarding and three major data views (signals, context, basket), which is likely complete for a public market data API. Minor gaps include no explicit historical or per-asset query tool, but core workflows are covered.
Agent-native crypto market-data over MCP+REST: order flow, whales, liquidations, calibrated scores
Market Data App MCP — wraps the Market Data App API (marketdata.app)
Live prices, perps, prediction markets and a paper trading desk over one MCP.
Crypto trading intelligence MCP — 34+ endpoints, x402 pay-per-use, AI agent strategy & execution