Founders Os vs SHIP — MCP Server Comparison | AllMCPs
Side-by-Side Model Context Protocol Comparison
Founders Os vs SHIP
In-depth architectural comparison of the Founders Os and SHIP MCP servers. Compare execution transports, security boundaries, tool capabilities, quality scores, and ready-to-paste client installation snippets for Claude, Cursor, Windsurf, and VS Code.
At a Glance & Executive Verdict
Founders Os
Workplace & Productivity · Local stdio
Quality: 61/100 (Good) | Auth: API Key required
SHIP
Workplace & Productivity · Remote HTTP/SSE
Quality: 52/100 (Good) | Auth: No auth required
Verdict Summary: Choose Founders Os if you need specialized Workplace & Productivity tools running via a local process. Choose SHIP if your workspace requires Workplace & Productivity integration with remote web transport. Both servers can be configured concurrently in your client's mcpServers manifest.
Which MCP Server Should You Choose?
Choose Founders Os when:
You need dedicated capabilities in the Workplace & Productivity domain.
You prefer local stdio subprocess transport architecture.
Your security boundary fits: API Key required (BYOK (Pay Provider Direct)).
You have access to required keys: SUPABASE_URL, SUPABASE_SECRET_KEY, FOUNDERS_OS_COMPANY_ID, FOUNDERS_OS_USER_ID, FOUNDERS_OS_TIMEZONE, EMBEDDING_PROVIDER, EMBEDDING_MODEL, EMBEDDING_DIM.
Self-hosted business context for your AI client: CRM, check points, automation triggers, financial ledger, tasks, playbooks, news feeds, projects, and semantic memory in one MCP server. Ask one question and it reads your CRM and books together. Your data stays in your own database. MIT licensed.
Assign Linear, Jira or GitHub issues to an AI coding agent team that plans, builds, reviews, tests.
Returns the running version of @ourthinktank/founders-os, the rendering contract version (used to detect plugin/server drift), how the connector was launched (launchMethod: npx | global | local | unknown) with a tailored howToUpdate string, the release channel (channel: stable | prerelease), the published head of that channel, and the database schema status (dbSchemaStatus: current | behind | ahead | untracked | unknown) with a howToUpdateDb step when action is needed. Version comparison is semver-aware and channel-aware: stable builds compare against the `latest` tag, prerelease builds against the `next` tag, so a prerelease that is ahead of stable is NOT reported as an update. versionStatus is one of current | update-available | ahead | unknown; updateAvailable is true only when a genuinely newer version exists on your channel (with updateTo naming it). Call at session start; if updateAvailable is true relay current vs updateTo and the howToUpdate step, and if dbSchemaStatus is behind or untracked relay the howToUpdateDb step.
get_usage_guide
Returns a detailed guide on how to use Founders OS - covering all six domains (CRM, Tasks, Tags, Finance, Feeds, Memory), surface tools, search protocols, common workflows, and tips. Call this when uncertain about how to approach a task.
Ready-to-Paste Client Configurations
Paste either (or both) of these JSON server blocks into your client config file (e.g. claude_desktop_config.json or ~/.cursor/mcp.json).
Founders Os is categorized under Workplace & Productivity and uses a local stdio subprocess. In contrast, SHIP belongs to Workplace & Productivity using remote streaming HTTP/SSE transport. Select Founders Os when you need capabilities focused on workplace & productivity and SHIP when you require tools for workplace & productivity.
Returns example prompts and workflows organized by domain (CRM, Tasks, Finance, Feeds, Memory, Surfaces). Call this when a user asks 'what can you do?', 'show me what I can do', 'help me get started', or wants to explore what Founders OS offers. Lighter than the full usage guide - focused on natural-language examples rather than technical reference.
list_demos
Returns available interactive demo walkthroughs bundled with Founders OS. When called without a name, returns a summary list of available demos. When called with a demo name, returns the full script (with shared presentation rules prepended) so the AI agent can run it directly. Call this when a user asks about demos, wants to explore features, or is onboarding.
add_customer
Create a new customer record. Customers are organizations or individuals that your business works with or is pursuing. If similar customers already exist, a `conflict` response is returned with options to use an existing record or create a new one. Pass skip_duplicate_check=true to bypass this on retry.
get_customer
Get a single customer with their contacts, recent interactions, and open tasks.
update_customer
Update fields on an existing customer record.
search_customers
Search customers by name, notes, city, state, or tags. Returns matching customers with summary info.
list_customers
List customers with optional filters. Returns paginated results with summary info. Response includes a render field with tiered rendering guidance - check it before composing your reply.
remove_customer
Remove a customer by archiving (sets phase to inactive, recoverable) or permanently deleting. On first call, returns a `conflict` with ARCHIVE / DELETE / CANCEL options. Pass mode after the user decides. Contacts cascade on delete; history is preserved on archive.
add_contact
Add a contact person to a customer organization. Contacts are individuals you interact with at that company.
+90 more tools listed on main page
SHIP Tools (71)
start_mission
Give an issue that is already in your tracker to the agent team. By default, the mission starts at the Planner. With a plan, it starts at the Builder. With an open pull request, it starts at the Reviewer or the Tester
create_mission
Create the issue and start the mission in one call, for work that has no issue yet
send_mission_instruction
Tell an active mission what to change, or record a note for the agent that runs next
inspect_mission
The full record of a mission: its stages, verdicts, provenance and session logs
list_missions
The missions of your projects, with what each mission does now
get_mission
One mission: its stage, its review and test results, its pull request, its agent runs and the run with the proof. With `view: "full"`, also its events and the outcome of each stage
pause_mission
Hold a mission before its next stage. The stage that runs now finishes
resume_mission
Continue a paused mission. When a checkpoint holds the mission, this approves the result of that stage
stop_mission
Stop a mission and every agent run of it. The pull request stays open
approve_mission_ceiling
Let a mission continue after it stops at its credit limit. The mission then uses more credits
merge_mission
Merge the pull request of a mission, with the merge method of the repository. On a merge conflict, SHIP starts the Builder to fix the conflict and merges later
decline_mission
Close the pull request of a mission without a merge