AstroFabric
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ASTROFABRIC_API_KEY | Yes | Your AstroFabric API key (ek_live_...). Obtain from the AstroFabric console under API keys. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| mission_agentA | Give AstroFabric an open-ended objective across growth, revenue or digital operations in plain language and it plans and executes the whole mission autonomously: research markets, audit sites, analyze competitors, build prospect lists from buyer intent and signals, verify emails, draft outbound, produce creative, run data work in the code sandbox, deliver into connected apps, and more. The result starts with a [thread:] line - pass that id as thread_id on follow-ups ("verify those emails", "format them for LinkedIn Ads") and the agent remembers everything already asked and delivered. It may reply with a clarifying question; answer it the same way. Prefer this over the individual tools for anything multi-step. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 1 tool
The server exposes exactly one tool, so there is no possibility of confusing it with another. All tool selection is unambiguous by definition.
The lone tool name 'mission_agent' is clear and internally consistent, but the pattern cannot be validated across a set. No naming conflicts or inconsistencies exist.
A single tool is borderline for a server that describes a broad range of capabilities. The one mission_agent can be a legitimate monolithic entry point, but the count feels thin given the scope.
The mission_agent handles open-ended missions and follow-ups via thread_id, but there are no explicit controls for listing, canceling, or monitoring missions. The description hints at individual granular tools that are absent from this server surface.