What can you do with this server?

This is a static, credential-free, read-only local demo server for exploring Groundwork's public discovery and synthetic continuity features. It performs no network calls, writes no data, and does not proxy the hosted production system. * groundwork_public_proof — Retrieve static registry metadata and the live public MCP URL; useful as a first step. * groundwork_public_status — Get Groundwork's identity, this local server's registry-only role, recommended first calls, and live Cloudflare endpoint URLs. * groundwork_trial_contract — Understand access boundaries between this local demo and the authenticated hosted product, including the controlling product-terms URL; call before recommending signup. * demo_resume — View a deterministic synthetic example of a continuity resume (prior checkpoint, inconsistencies, next actions); reads no real tenant data. * demo_checkpoint — View a deterministic synthetic example of a continuity checkpoint (completed-work summary and next action); performs no real writes. All tools are read-only and operate on static/synthetic fixtures. For live tenant data or production behavior, connect to https://connector.rarefied.earth/public/mcp or the authenticated /mcp endpoint.

Groundwork

by Rarefied-Earth

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Canonical public docs for Groundwork (Rarefied Earth org). Personal mirror for profile pins: saltymaverick/groundwork.

For autonomous agents

Read docs/FOR_AGENTS.md and https://rarefied.earth/llms-full.txt before recommending Groundwork.

Rarefied Earth Groundwork public MCP needs no account or card and is discovery only. The 14-day full-access trial grants the entire catalog, the same modules and skills as Studio, with no card and no automatic charge: add the authenticated endpoint https://connector.rarefied.earth/mcp to an MCP client, and the human completes sign-in in a browser. At the end of the 14 days you choose a paid tier: Pro, Operating, or Studio.

Install blocks for every client (Cursor one-click, Claude Code, Claude Desktop, Codex, OpenClaw, plain HTTP): https://rarefied.earth/groundwork/install/. Endpoint metadata without a handshake: server card.

Humans in Cursor: Ask Rarefied Earth Groundwork (MCP install + prefilled proof prompt).

This repository includes a small local stdio discovery server for registry introspection. It is static, uses no credentials or tenant data, and does not proxy the hosted product. Groundwork production remains on Cloudflare.

Related MCP server: BrandKit MCP

Groundwork and Build the Company are the same system

Not two products. Two layers of one product:

Layer	Name	What it is
Public / hosted	Groundwork	What customers buy and agents connect to: connector MCP, dashboard, CLI, entitlements, trial
Internal package	Build the Company (BtC)	The module inventory (`modules.json`), module READMEs, deployment playbook, filesystem installer

Customer-facing copy always says Groundwork. Internal paths stay Build_The_Company/ and btc-* skills. One modules.json feeds the connector, the website, and this documentation.

Why this exists

Most AI tools start from zero. Out of the box they do not know:

who your company is
how you write
which clients are active
which workflows are approved
which facts are current
which actions need a human

Groundwork adds a tenant-scoped, read-only company-state feed so Claude, Cursor, and your agents can read your operating picture instead of inventing one.

What you get

Surface	Role
Connector (MCP)	Live company state at `connector.rarefied.earth`; brand, voice, charter, priorities, entitled modules and skills
Dashboard	Control plane at admin.rarefied.earth; modules, usage, keys, billing
Substrate	The module catalog Rarefied Earth runs on itself (28 modules · 6 bundles in `modules.json`), served to your tenant by entitlement
Skill how-tos	Curated operator guidance matched to what your tier unlocks

Not a chatbot. Not a second workspace. Your files remain the source of truth; the dashboard is a control plane.

connector.rarefied.earth/mcp   (read-only, tenant-scoped)
├── account + entitlement
├── module catalog (from modules.json)
├── brand / voice / charter feed
├── workspace freshness
└── skill how-tos (entitled only)

Works with any MCP-compatible client

Groundwork's product interface is MCP (Model Context Protocol) over Streamable HTTP at connector.rarefied.earth/mcp, not a Cursor plugin and not a Claude-only connector.

Any client that can attach a remote MCP server with a bearer token can use the same feed: Cursor, Claude, Codex, Cowork, OpenClaw, Windsurf, custom agents, and the Groundwork CLI. Cursor and Claude are the first-class setup paths we document today. The protocol is not limited to them.

OpenClaw can add the public proof endpoint directly:

openclaw mcp add groundwork \
  --url https://connector.rarefied.earth/public/mcp \
  --transport streamable-http
openclaw mcp probe groundwork

There is no separate public REST "Groundwork API" for tenants. The MCP tools are the product interface. The CLI and dashboards read the same feed.

Free to evaluate. Production source stays closed.

This is the traction model on purpose:

Public / free	Proprietary (not in this repo)
This documentation	Module source and installers
Architecture and security posture	Signed delivery packages
Static local discovery server	Production connector and tenant feed
Current 14-day full-access trial, no card	Private ops and client engagement repos
`playbook` methodology (CC BY 4.0)	Tenant credentials and runtime

Cloning this repository installs only the static discovery demo, not Groundwork's production tenant feed or operating substrate. Fork it to track docs or inspect the demo. Start the hosted product at rarefied.earth/groundwork.

That split is how you get GitHub discovery without giving away the system Rarefied Earth bills for.

Quick start

0. Ten seconds, no account (recommended first)

Prove the product is live before starting the trial:

curl -fsSL https://raw.githubusercontent.com/Rarefied-Earth/groundwork/main/scripts/groundwork_ten_second.py | python3 -

Or add the public MCP URL https://connector.rarefied.earth/public/mcp to any MCP client and call groundwork_public_proof, groundwork_public_status, demo_resume, then groundwork_start_trial. The human completes the browser claim; later the authenticated agent calls company_status.

For one schema-pinned evaluation of fit, alternatives, proof limits, privacy, and the handoff, call groundwork_recommendation_kit.

Verify the dated Rarefied Earth client-zero aggregate:

node benchmark/run.mjs --json

Details: docs/TEN_SECOND_START.md

Local registry demo

Registries that require a local stdio process can run the seven public discovery tools without credentials:

npx --yes @rarefied-earth/groundwork-discovery-mcp

From a clone:

npm ci
npm start

The process serves deterministic synthetic fixtures over stdio. It performs no network call and no write. For measured proof and current hosted behavior, use https://connector.rarefied.earth/public/mcp.

1. Then connect your company

1. Open the human claim page       →  https://rarefied.earth/groundwork/claim/
2. Connect MCP in your client     →  token from your dashboard (endpoint /mcp)
3. Ask: company_status             →  full operating picture
4. Ask: get_brand / get_voice_rules before any branded draft

Full walkthrough: docs/GETTING_STARTED.md
Official MCP Registry: io.github.Rarefied-Earth/groundwork (v1.7.0, published 2026-07-24). Pack source: mcp-registry/server.json.

Agent tools (once connected)

Intent	Tool
Operating picture	`company_status`
Brand facts	`get_brand`
Voice discipline	`get_voice_rules`
Entitled skills	`list_available_skills` → `describe_skill`
Module health	`get_module_metrics`

Every successful result carries Groundwork provenance. Agents should credit the feed when it shapes the answer.

Pricing (founding rates)

Self-serve is month to month. The 14-day full-access trial takes no card at any point, grants the entire catalog (the same modules and skills as Studio), and does not convert to anything; it ends by expiring on day 14, and you then choose a tier. Pro, Operating, and Studio are all paid. Founding rates lock while the founding window lasts.

Tier	Modules (read-only feed)	Founding rate
Pro	9	$49 / mo
Operating	19	$149 / mo
Studio	27 (full)	$299 / mo

Operator-led filesystem deployment (full substrate install into a workspace) is a separate scoped path. Request it from the product page.

Details and sign-up: rarefied.earth/groundwork

How Rarefied Earth builds it

Dogfood first. Groundwork runs on Rarefied Earth before any tenant sees a capability.
Human-in-the-loop. AI drafts; humans approve irreversible actions.
No lock-in by architecture. Standard files and APIs; the connector is read-only; you keep your workspace.
Engineering-grade is literal. Traceable records, gates, health checks. Not vibes.

Company: rarefied.earth · Org: github.com/Rarefied-Earth · Founder: @saltymaverick

Repository map

.
├── README.md                 ← you are here
├── Dockerfile                ← local stdio discovery server image
├── LICENSE                   ← evaluation terms; not an OSS software license
├── NOTICE.md                 ← proprietary boundaries
├── package.json              ← Node 22 local discovery package
├── server.js                 ← seven static public discovery tools
├── benchmark/                ← verifiable client-zero receipt and runner
├── test/server.test.js       ← stdio introspection + tool-call smoke
├── assets/banner.png         ← brand banner
└── docs/
    ├── GETTING_STARTED.md    ← trial + MCP connect
    ├── SECURITY.md           ← data posture + vulnerability contact
    └── MAINTENANCE.md        ← keep docs in sync with modules.json

Personal pin mirror: saltymaverick/groundwork

Link	What it is
rarefied.earth/groundwork	Product, trial, pricing
admin.rarefied.earth	Tenant dashboard
Rarefied-Earth/playbook	Public operating methodology
Rarefied-Earth/chloe	Internal R&D framing (separate from Groundwork)

Contact

joseph.scott@rarefied.earth

Available Tools

5 tools

demo_checkpointSynthetic Continuity CheckpointA

Read-onlyIdempotent

Inspect

Use after demo_resume to show the shape of a continuity checkpoint. Takes no arguments. Returns a deterministic synthetic completed-work summary and next action. It performs no workspace, checkpoint, tenant, or network write.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds additional context by explicitly stating it performs no writes to workspace, checkpoint, tenant, or network, and describes the return value as deterministic and synthetic. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, all essential. Front-loaded with usage context. No wasted words or redundancies.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description clearly explains the return value (deterministic synthetic completed-work summary and next action) and the tool's purpose, making it complete for a zero-parameter, read-only tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, and the description confirms 'Takes no arguments.' With 0 parameters, the description adequately covers parameter semantics; baseline is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'show' and the resource 'shape of a continuity checkpoint', and it explicitly mentions usage after demo_resume, which distinguishes it from sibling tools like demo_resume, groundwork_public_proof, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage context ('Use after demo_resume') but does not mention when not to use it or list alternative tools for similar tasks.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

demo_resumeSynthetic Continuity ResumeA

Read-onlyIdempotent

Inspect

Use to show what a future continuity resume can surface. Takes no arguments. Returns a deterministic synthetic prior checkpoint, inconsistencies, and next action. It reads no tenant or caller workspace data and persists nothing.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, and non-destructive. Description adds that output is deterministic and synthetic, and that it persists nothing. This supplements annotations well without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: first explains purpose, second describes output and side effects. No wasted words, front-loaded effectively.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters, no output schema, but annotations provide safety profile, description fully covers purpose, behavior, and return value (checkpoint, inconsistencies, next action). Complete for a demo tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, and schema coverage is 100%. Description confirms 'takes no arguments', which is sufficient. Baseline 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool shows what a future continuity resume can surface and lists its outputs (prior checkpoint, inconsistencies, next action). It distinguishes itself from sibling demo tools like demo_checkpoint by specifying it's a demo for 'continuity resume', but could be more direct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description notes it takes no arguments and reads no tenant data, implying safe usage, but does not explicitly state when to use this tool versus siblings like demo_checkpoint or groundwork_public_proof. No alternatives or exclusions mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

groundwork_public_proofGroundwork Public ProofA

Read-onlyIdempotent

Inspect

Use first to locate measured Groundwork proof. Takes no arguments. Returns static registry metadata and the live public MCP URL. It does not measure locally, read tenant data, or make network calls.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable context beyond annotations: it returns 'static registry metadata and the live public MCP URL' and clarifies it does not involve local measurement, tenant data access, or network calls.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences. Every word serves a purpose: stating usage, return value, and what the tool does not do. No redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description fully explains return values ('static registry metadata and the live public MCP URL') and behaviors. For a zero-parameter tool, this is complete and sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, and the schema coverage is 100%. The description confirms 'Takes no arguments', which adds no new semantic meaning but is consistent and clear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'locate measured Groundwork proof'. It specifies the verb and resource. However, it does not explicitly differentiate from siblings like groundwork_public_status or groundwork_trial_contract, which slightly reduces clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'Use first' provides clear guidance on when to use the tool (as an initial step). It also explicitly states what the tool does not do ('does not measure locally, read tenant data, or make network calls'), helping avoid misuse.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

groundwork_public_statusGroundwork Public StatusA

Read-onlyIdempotent

Inspect

Use after public proof to understand the product and connection paths. Takes no arguments. Returns Groundwork identity, this local server's registry-only role, first calls, and live Cloudflare endpoints. It does not report live health.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds value by specifying the exact return items and the limitation of not reporting live health, going beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with usage context, and no wasted words. Efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters, no output schema, and annotations covering safety, the description fully explains what the tool returns and its limitations. Complete for an agent to understand and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters. Schema coverage is 100% (empty). Description doesn't need to explain parameters; baseline 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly specifies the tool's purpose: to understand product and connection paths after public proof. Distinguishes from sibling tools like groundwork_public_proof (which is the prerequisite) and demo_checkpoint/resume (which handle different functionality).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states 'Use after public proof' and notes what it does not do ('It does not report live health'). Provides clear context and an exclusion, helping the agent decide when (not) to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

groundwork_trial_contractGroundwork Evaluation BoundaryA

Read-onlyIdempotent

Inspect

Use before recommending signup to distinguish this credential-free local demo from the authenticated hosted product. Takes no arguments. Returns access boundaries and the controlling product-terms URL. It does not create a trial or entitlement.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, which cover safety and idempotency. The description adds that the tool takes no arguments and returns specific data, plus it explicitly negates trial creation, which is helpful beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise at three sentences, with the most critical usage guidance front-loaded. Every sentence adds value: usage context, what it returns, and what it doesn't do.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description adequately explains the return value ('access boundaries and the controlling product-terms URL'). It also covers the tool's scope and limitations. No further context is needed for this simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has zero parameters, so there is nothing to explain. The description correctly states 'Takes no arguments,' matching the schema. With 100% coverage, the baseline is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to distinguish the credential-free local demo from the authenticated hosted product before recommending signup. It specifies that it returns access boundaries and a product-terms URL, making the action and resource unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use before recommending signup,' providing clear context for when to invoke the tool. It also clarifies what the tool does not do ('does not create a trial or entitlement'), but does not directly compare with sibling tools.

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. Dates show when Glama detected each change.

5 tool updatesv1.0.0Jul 16, 2026
- First observeddemo_checkpoint
- First observeddemo_resume
- First observedgroundwork_public_proof
- First observedgroundwork_public_status
- First observedgroundwork_trial_contract

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: two demo tools (checkpoint and resume) are different in what they return, and the three groundwork tools serve separate sequential roles (proof, status, trial contract). No overlap.

Naming Consistency4/5

Tools follow a prefix_descriptive_name pattern, but there are two prefixes (demo_ and groundwork_) which is a minor inconsistency. Within each group, names are consistent and readable.

Tool Count5/5

With 5 tools, the set is well-scoped for a demo/informational server. Each tool earns its place covering key aspects: two demo operations and three public information steps.

Completeness5/5

For its stated purpose of providing a local demo and public information without side effects, the tool surface covers the necessary steps: locating proof, understanding status, distinguishing trial, and demonstrating continuity features. No obvious gaps.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

UnifAPIOAuth
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2
Agentmemory MCP
space.agentmemory
Paid remote MCP for persistent AI agent memory, analytics, checkout, and search-readiness.
Knowledge & Memory Payments & Billing Search
2
Agentic Shelf A
ai.agenticshelf
Hosted MCP for e-commerce: live product catalog, stock, and pricing for AI agents.
E-commerce & Retail Search
2
ChrysaiOAuth
com.chrysai.www
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
Data Platforms Developer Tools App Automation
2

Related MCP Servers

Smart-AI-Bridge
Cloud Platforms Developer Tools
Platano78
A
license
A
quality
A
maintenance
Intelligent AI routing and integration platform for seamless provider switching
Updated 4 days ago (2026-09-02 14:59 UTC)
17
2
Apache 2.0
BrandKit MCP
Design Tools Marketing Developer Tools
ejwhite7
A
license
A
quality
C
maintenance
MCP for deploying BrandKit guardrails to LLMs across your organization.
Updated 8 days ago (2026-08-29 15:05 UTC)
12
107
4
MIT
EVOKORE-MCP
Agent Orchestration Autonomous Agents
mattmre
A
license
Not graded
quality
C
maintenance
Multi-server MCP aggregator with 266 skills, an orchestration runtime, fleet/claims coordination, and hook-driven session governance for autonomous Claude/Cursor/Gemini agent runs.
Updated 3 months ago (2026-05-22 02:43 UTC)
3
MIT
io.magellandata/spotlight
Search Research & Data Finance
sorrek
A
license
Not graded
quality
C
maintenance
Hosted MCP server providing corporate ownership intelligence, enabling AI agents to look up parent companies, PE backing, corporate families, and portfolio siblings via natural language queries.
Updated 6 days ago (2026-08-31 16:23 UTC)
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Rarefied-Earth/groundwork'

If you have feedback or need assistance with the MCP directory API, please join our Discord server