AstroFabric
This server lets you hand an open-ended business objective to an autonomous agent (mission_agent) that plans and executes the whole mission, returning results with follow-up memory via thread IDs.
Run autonomous missions in plain language across growth, revenue, or digital operations
Research markets, audit websites, and analyze competitors
Build prospect lists from buyer intent and business signals
Enrich company and person data, including technographics and hiring signals
Verify corporate records and contact/email addresses
Draft outbound messages and produce creative assets
Run data transformations/work in a code sandbox
Deliver structured intelligence into connected CRMs, ad platforms, sheets, and other apps
Continue missions with full memory by passing
thread_idon follow-upsAccess the same functionality via remote HTTP MCP endpoint, local stdio server, or CLI
AstroFabric MCP Server
AstroFabric is agentic AI for business intelligence: autonomous data infrastructure that turns strategic objectives into verified datasets and live intelligence streams. Its agents discover companies and people, execute deep enrichment, verify corporate and contact records, monitor real-time business and marketplace signals, score and segment targets, build matched audiences, and deliver structured intelligence into CRMs, commerce systems, ad platforms, operational sheets, messaging channels, or any application through REST, MCP and CLI. Every workflow carries evidence and operates within approval gates, audit trails and credit ceilings. This MCP server puts that infrastructure behind your editor, give mission_agent an open-ended objective in plain language and it plans and executes the mission, returning the finished data with the evidence behind it..
This repository is both the connector for the hosted AstroFabric MCP endpoint (add the remote URL with your API key and start working) and a runnable stdio server for clients that prefer a local process - see Run it locally.
Website: https://www.astrofabric.ai
Endpoint:
https://www.astrofabric.ai/api/mcp(Streamable HTTP)
Prerequisites
An AstroFabric workspace on a paid plan - sign up at https://www.astrofabric.ai
An API key: in the AstroFabric console, open API keys → Create key, and copy the
ek_live_...token (it is shown once).
Related MCP server: Agentic Control Framework (ACF)
Setup
Every client uses the same endpoint (https://www.astrofabric.ai/api/mcp) and the same key. Pick yours:
claude mcp add --transport http astrofabric https://www.astrofabric.ai/api/mcp --header "Authorization: Bearer ek_live_YOUR_KEY_HERE"Add a custom connector with the bare URL and sign in when prompted - the server walks you through AstroFabric sign-in and hands the client a scoped key you can revoke from the console:
https://www.astrofabric.ai/api/mcpAdd to .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):
{
"mcpServers": {
"astrofabric": {
"url": "https://www.astrofabric.ai/api/mcp",
"headers": { "Authorization": "Bearer ek_live_YOUR_KEY_HERE" }
}
}
}Add to cline_mcp_settings.json (Cline → MCP Servers → Configure, or Remote Servers → add by URL):
{
"mcpServers": {
"astrofabric": {
"type": "streamableHttp",
"url": "https://www.astrofabric.ai/api/mcp",
"headers": {
"Authorization": "Bearer ek_live_YOUR_KEY_HERE"
},
"disabled": false,
"autoApprove": []
}
}
}Add to .vscode/mcp.json:
{
"servers": {
"astrofabric": {
"type": "http",
"url": "https://www.astrofabric.ai/api/mcp",
"headers": { "Authorization": "Bearer ek_live_YOUR_KEY_HERE" }
}
}
}Add to ~/.codex/config.toml:
[mcp_servers.astrofabric]
url = "https://www.astrofabric.ai/api/mcp"
http_headers = { "Authorization" = "Bearer ek_live_YOUR_KEY_HERE" }Add to ~/.gemini/settings.json under mcpServers:
{
"astrofabric": {
"httpUrl": "https://www.astrofabric.ai/api/mcp",
"headers": { "Authorization": "Bearer ek_live_YOUR_KEY_HERE" }
}
}Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"astrofabric": {
"serverUrl": "https://www.astrofabric.ai/api/mcp",
"headers": { "Authorization": "Bearer ek_live_YOUR_KEY_HERE" }
}
}
}Shortcut: with the CLI installed, astrofabric connect <client> prints your client's config with your key already filled in.
If your client cannot send headers, the key can ride the URL instead: https://www.astrofabric.ai/api/mcp?key=ek_live_YOUR_KEY_HERE - treat that whole URL as a secret.
Two tool surfaces
Default (the URL above): one tool,
mission_agent- the autonomous mission runner. Best for editors: one entry in your tool list, the whole platform behind it.Full catalog: append
?tools=allto the URL to also expose every individual data and execution tool (company and person data, enrichment, email verification, technographics, business signals, lists, audiences and delivery), plus any MCP servers your workspace has connected.
Using it
Ask for outcomes, not steps:
"Build a list of 40 companies showing buying intent on warehouse robotics, verify emails, and draft a first touch for each."
"Enrich this account list with company size, technology stack and recent hiring signals, then return the best-fit accounts with supporting evidence."
Results start with a [thread:<id>] line. Pass that id as thread_id on follow-ups ("verify those emails", "format them for LinkedIn Ads") and the agent continues with full memory of everything already asked and delivered. It may reply with a clarifying question; answer it the same way.
Run it locally (stdio)
This repository is also a runnable stdio MCP server - the same mission_agent tool, executing missions through the AstroFabric platform with your key. For clients that prefer a local process over a remote URL:
{
"mcpServers": {
"astrofabric": {
"command": "npx",
"args": ["-y", "github:sam1siam/astrofabric-mcp"],
"env": { "ASTROFABRIC_API_KEY": "ek_live_YOUR_KEY_HERE" }
}
}
}Or with Docker: docker build -t astrofabric-mcp . && docker run -i --rm -e ASTROFABRIC_API_KEY=ek_live_... astrofabric-mcp
Prefer a terminal? The CLI
The same platform ships as a zero-dependency CLI (astrofabric on npm):
npm install -g astrofabric
astrofabric login --key ek_live_...
astrofabric run "Find 20 companies hiring SDRs, enrich their profiles and return a verified prospect list"In a coding agent (Claude Code, Codex, Gemini CLI), the whole setup is one prompt: "Install the AstroFabric CLI for me, then run astrofabric docs to learn it." And astrofabric connect cursor (or claude-code, codex, gemini, vscode, windsurf) prints ready-to-paste MCP config per client.
Notes
Missions bill against your workspace's credits; the console's Usage page shows every run.
Writes to connected systems honor your workspace's approval settings - autonomous writes can be gated to a human approval queue.
OAuth 2.1 (dynamic client registration + PKCE) is also supported via standard discovery, for clients that prefer sign-in over keys.
License
The contents of this connector repository are MIT licensed. The AstroFabric platform is a commercial service.
Available Tools
1 toolmission_agentMission Agent (autonomous missions)A
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.
| Name | Required | Description | Default |
|---|---|---|---|
| objective | Yes | What to accomplish, e.g. "Build a list of 100 companies showing high interest in building insulation" | |
| thread_id | No | The thread id from a previous result, to continue that mission with full memory |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations by explaining autonomous planning/execution, the [thread:<id>] result prefix, memory across follow-ups, and the possibility of a clarifying question. It also mentions capabilities like running data work in the code sandbox and delivering into connected apps, which gives an agent a concrete sense of side effects. No contradiction with annotations was mentioned.
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 dense but every sentence adds new information: core functionality, key output format, continuation pattern, clarification behavior, and usage preference. The front-loaded sentence explains scope first, followed by operational details. It is aligned with the best vertex for high-functioning agents.
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?
Given the tool is an autonomous agent with no sibling tools and no output schema, the description surprisingly covers everything essential: what the objective should be, what outcomes can be expected, how to start, how to continue, how to handle clarifying questions, and when to prefer it. The emptiness of a formal output schema is compensated by the explicit mention of the thread line at the beginning. This is a high-quality, self-sufficient description.
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 input schema already covers 100% of parameters with meaningful descriptions and an example for objective. The description reinforces thread_id usage in the continuation context but does not materially add new semantic details beyond the schema. This matches the baseline where the schema carries the parameter-load.
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 clearly states that the tool takes a plain-language objective and autonomously plans/executes a multi-step mission across growth, revenue, and digital operations. It lists concrete actions (research, audits, competitor analysis, email verification) and explicitly contrasts itself with individual tools. This goes well beyond a vague restatement of the name.
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?
It explicitly says 'Prefer this over the individual tools for anything multi-step', which specifies when to use it and strongly implies when not to use it (single-step operations). It also documents the follow-up workflow using thread_id and how to respond to clarifying questions. This is strong, actionable usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v1.1.0- First observed
mission_agent
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.
Maintenance
Related MCP Connectors
Connect, monitor, and control AI agents — tasks, approvals, schedules, and governance.
Agent-native security, trust, reliability, data and procurement tools for AI workflows.
Let AI agents query data and act across all your business apps via MCP.
Control plane for autonomous software labor. Agents claim objectives over MCP with audit trail.
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceEnterprise-grade MCP server with multi-agent system for business AI transformation across finance, healthcare, retail, and other domains. Provides specialized AI agents for data analysis, API execution, business validation, and report generation with real-time monitoring and observability.-
- AlicenseDqualityDmaintenanceAI-native orchestration layer with 80+ tools for task management, code editing, browser automation, terminal control, and persistent memory across CLI, local MCP, and cloud deployments.694 npm31ISC
- AlicenseAqualityAmaintenanceAI Agent Mission Control — 200+ MCP tools across 31 domains. Manage agents, experiments, workflows, crews, skills, tools, credentials, approvals, signals, budgets, marketplace, knowledge bases, chatbots, and more. Self-hosted, open-source (AGPL-3.0). Supports stdio + Streamable HTTP/SSE with OAuth 2.0 auth.3468AGPL 3.0
- AlicenseNot gradedqualityBmaintenanceProvides AI agents with operational customer context, including typed revenue objects, persistent state, scoped tools, and human-in-the-loop handoffs through MCP, REST, and CLI.11 npm12Apache 2.0