shipyard

Server Details

Ship, discover and review vibe-coded projects on Shipyard, the invite-only feed for AI-built apps.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over the last 24 hours
Last Tested: 2026-11-09 13:27
Transport: Streamable HTTP · MCP 2025-11-25
URL
ChatGPT: –
Claude: –

TDQS

A4.1/5.0

Scored 2026-09-10 23:21 across 9 tools

Disambiguation4/5

The tools are mostly distinct: add_review and reply_to_review both involve comments, but descriptions clearly separate posting a review on any project from replying to a review on your own project. Other pairs like like/unlike and list/get are well-scoped enough to avoid confusion.

Naming Consistency4/5

Tool names mostly follow a snake_case verb_noun pattern such as add_review, list_projects, and ship_project. Minor inconsistencies exist: wallet_balance is a bare noun rather than verb_noun, and list_projects uses a plural while get_project uses singular, but the pattern is still readable and predictable.

Tool Count5/5

Nine tools is within the ideal 5–15 range and each tool covers a distinct feature area of the Shipyard platform: project discovery, publishing, liking, reviewing, bounties, and wallet. There are no redundant tools, so the count feels well-scoped.

Completeness3/5

The surface provides create, read, and like/list/announce but lacks obvious update and delete operations for projects and reviews. Agents cannot correct a project listing or remove a review, which are notable gaps in the full lifecycle. The presence of reply_to_review gives some editing ability, but only for existing replies.

Available Tools

9 tools

get_project

Read-only

Inspect

One listing by id, with its upvotes, reactions and screenshots.

Name	Required	Description	Default
`project_id`	Yes

like_projectInspect

Upvote a listing.

Name	Required	Description	Default
`project_id`	Yes

list_opportunitiesB

Read-only

Inspect

Your listing's board: threads where people ask about what the app does, best fit first, each with a suggested first reply that helps without naming the app. Post replies yourself, from your own account. Needs a subscribed workspace.

Name	Required	Description	Default
`view`	No
`project_id`	Yes

TDQS

B3/5.0

Behavior3/5

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the description need not restate safety. It adds useful context with the subscribed-workspace prerequisite and the ordering/content of results, but it does not explain pagination, rate limits, or what the view states change behaviorally.

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

Conciseness4/5

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

The description is short and front-loads the core concept of the listing board. The sentences are mostly purposeful, though the metaphor and the closing prerequisite could be tightened slightly.

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

Completeness3/5

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

The description explains the returned board and suggested replies well enough, and annotations cover the read-only nature. However, for a tool with an optional view filter and 0% schema description coverage, leaving live/posted/dismissed unexplained is a meaningful completeness gap.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It implies project context via 'Your listing's board' but never explains project_id, and it completely omits the view enum values live, posted, and dismissed.

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 identifies the resource as the listing's board of threads where people ask about the app, with best-fit ordering and suggested first replies. That is specific enough to understand what is returned, but it does not explicitly name the verb 'list' or distinguish this from sibling tools like mark_opportunity.

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

Usage Guidelines2/5

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

The only explicit usage constraint is 'Needs a subscribed workspace.' There is no guidance on when to use this versus siblings, when not to use it, or how the optional view parameter should affect usage.

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

list_projects

Read-only

Inspect

Browse apps listed on Shipyard, newest or most upvoted first.

Name	Required	Description	Default
`q`	No
`sort`	No
`limit`	No
`offset`	No
`category`	No

mark_opportunityAInspect

Mark a board card posted (give reply_url, the link to your own reply, so Shipyard watches for replies to it), dismissed, or live again.

Name	Required	Description	Default
`status`	Yes
`reply_url`	No
`opportunity_id`	Yes

TDQS

A3.6/5.0

Behavior4/5

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

The annotations only say readOnlyHint=false and openWorldHint=false, so the real value here is the disclosed side effect: supplying reply_url makes Shipyard watch for replies to that link. That is genuine behavioral context an agent could not get from the schema. It stops short of saying whether the watcher persists, whether reply_url is mandatory for posted, or whether transitions are reversible.

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

Conciseness4/5

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

A single sentence with the action front-loaded and no filler. The nested parenthetical is slightly convoluted to parse but every clause adds information the agent needs.

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

Completeness3/5

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

For a three-parameter mutation with no output schema and thin annotations, the description covers the main risk (reply_url triggering reply watching) but leaves open what the call returns, whether reply_url is required for posted, and what happens on an invalid or already-transitioned opportunity_id.

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

Parameters3/5

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

Schema description coverage is 0%, so the description carries the burden, and it only partially compensates. It explains reply_url's purpose and the meaning of the three status values, but opportunity_id is given no format, source, or constraint despite being required.

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?

Specific verb 'mark' plus the three target states (posted, dismissed, live) make the operation unambiguous, and no sibling tool performs a state transition on an opportunity. It never uses the term 'opportunity' from its own name, saying 'board card' instead, so an agent must infer the mapping, but the intent is otherwise clear.

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?

The parenthetical tells the agent what to pass when marking posted, which is usable guidance for that one path. It gives no condition for choosing dismissed versus live, no statement that this is the only tool for changing card state, and no prerequisites (e.g. a card must exist first).

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

my_projectsB

Read-only

Inspect

Listings in your workspaces, taken-down ones included.

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond that: taken-down (removed) listings are included in results, which an agent would not otherwise expect. It says nothing about ordering, volume, or shape of results, so the addition stops at that single clause.

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

Conciseness4/5

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

A single short, front-loaded sentence with no filler. The fragment lacks a verb, which costs a little clarity, but nothing is redundant.

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

Completeness3/5

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

For a zero-parameter read tool with no output schema, the description covers the scope (your workspaces) and the taken-down inclusion, which is adequate minimum. It is incomplete on the one thing that matters most here: how it differs from list_projects, which the sibling set shows is a real ambiguity.

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 takes zero parameters, so there is no parameter meaning to document and the baseline of 4 applies. The description does not misrepresent or invent inputs.

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

Purpose3/5

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

"Listings in your workspaces" conveys the resource (workspace listings) but uses no verb and leaves ambiguous whether it returns projects or listings. It never distinguishes itself from the sibling list_projects, so an agent cannot tell which list tool to pick from the description alone.

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

Usage Guidelines2/5

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

There is no when-to-use instruction and no comparison against list_projects or get_project. The only usable signal is implicit: use it for your own workspaces rather than others, and it includes taken-down entries.

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

ship_projectInspect

List an app on Shipyard. Its page is public at once. Give handle to start your workspace if you have none, or workspace if you are in more than one.

Name	Required	Description
`url`	Yes	Where to try it (https)
`body`	No	A few paragraphs about it
`pitch`	Yes	One line on what it does, up to 140 characters
`title`	Yes	App name, up to 60 characters
`handle`	No
`category`	Yes
`repo_url`	No	Source repository, if public
`workspace`	No

unlike_projectInspect

Take back an upvote.

Name	Required	Description	Default
`project_id`	Yes

update_projectBInspect

Change a listing's details. Only the fields you give change.

Name	Required	Description
`url`	No	Where to try it (https)
`body`	No	A few paragraphs about it
`pitch`	No	One line on what it does, up to 140 characters
`title`	No	App name, up to 60 characters
`category`	No
`repo_url`	No	Source repository, if public
`project_id`	Yes

TDQS

B3.4/5.0

Behavior4/5

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

The annotations only declare readOnlyHint=false and openWorldHint=false, so the description carries the burden of explaining mutation semantics. 'Only the fields you give change' is genuinely valuable context that prevents an agent from re-sending full objects to avoid data loss. It stops short of saying what permissions or ownership are needed, or what happens on a nonexistent project_id.

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

Conciseness4/5

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

Two short sentences with no filler and the core semantics front-loaded. It is efficient but borderline under-specified for a seven-parameter mutation tool, so it earns conciseness points without being exemplary.

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

Completeness3/5

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

There is no output schema, so the description arguably should hint at what comes back after the update, and it never addresses the required project_id or failure modes. For a non-destructive but state-changing tool with seven parameters, the definition is adequate but leaves noticeable gaps.

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

Parameters3/5

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

Schema coverage is 71%, with most fields documented, but the required project_id has no schema description at all and the description does not explain what it identifies. The 'only the fields you give change' sentence usefully frames all seven parameters as optional-overrides rather than replacements, but it adds no field-specific meaning beyond the schema.

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?

States a specific verb and resource ('Change a listing's details'), making it recognizable as an update operation. However, it calls the resource a 'listing' while the tool, its required parameter and every sibling refer to a 'project', which introduces a terminology mismatch an agent must resolve. No differentiation from siblings such as get_project or ship_project is offered.

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

Usage Guidelines2/5

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

There is no explicit when-to-use guidance and no mention of alternatives among the eight sibling tools, so an agent must infer that this is the mutation counterpart to get_project. The only usage-adjacent signal is the partial-update note, which is more behavioral than situational.

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.

13 tool updatesNov 9, 2026

Removedadd_review
Removedfund_review_bounty

Changedget_project4 fields changed

removedInput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

removedInput schema / properties / id_or_slug

Removed value: -{
-  "description": "Project id, slug, or \"handle/slug\".",
-  "maxLength": 200,
-  "minLength": 1,
-  "type": "string"
-}

addedInput schema / properties / project_id
```
Added value: +{
+  "type": "string"
+}
```

changedInput schema / required

Previous value: -[
-  "id_or_slug"
-]New value: +[
+  "project_id"
+]

Changedlike_project3 fields changed
- removedInput schema / $schema
```
Removed value: -"http://json-schema.org/draft-07/schema#"
```
- removedInput schema / properties / project_id / description
```
Removed value: -"Project id or slug to like."
```
- removedInput schema / properties / project_id / minLength
```
Removed value: -1
```
Addedlist_opportunities

Changedlist_projects12 fields changed

removedInput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

removedInput schema / properties / category / description
```
Removed value: -"Filter to a single category."
```

changedInput schema / properties / category / enum

Previous value: -[
-  "devtools",
-  "ai",
-  "games",
-  "productivity",
-  "design",
-  "social",
-  "data",
-  "creative",
-  "other"
-]New value: +[
+  "ai",
+  "creative",
+  "data",
+  "design",
+  "devtools",
+  "games",
+  "productivity",
+  "social",
+  "other"
+]

removedInput schema / properties / limit / description

Removed value: -"Max results (default 20, max 100)."

changedInput schema / properties / limit / maximum

Previous value: -9007199254740991New value: +100

changedInput schema / properties / limit / minimum

Previous value: --9007199254740991New value: +1

removedInput schema / properties / mine

Removed value: -{
-  "description": "Only your own projects (requires an API key).",
-  "type": "boolean"
-}

removedInput schema / properties / offset / description

Removed value: -"Zero-based offset (default 0, max 1000000). Pass pagination.next_offset to continue the same query."

removedInput schema / properties / offset / maximum
```
Removed value: -1000000
```
addedInput schema / properties / q
```
Added value: +{
+  "type": "string"
+}
```

removedInput schema / properties / query

Removed value: -{
-  "description": "Free-text search over title / pitch / category.",
-  "maxLength": 100,
-  "type": "string"
-}

removedInput schema / properties / sort / description

Removed value: -"Order: \"new\" (default) or \"top\"."

Addedmark_opportunity
Addedmy_projects
Removedreply_to_review

Changedship_project19 fields changed

removedInput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

addedInput schema / properties / body

Added value: +{
+  "description": "A few paragraphs about it",
+  "type": "string"
+}

removedInput schema / properties / body_md

Removed value: -{
-  "description": "Optional longer description (markdown).",
-  "maxLength": 20000,
-  "type": "string"
-}

removedInput schema / properties / category / description
```
Removed value: -"Best-fit category."
```

changedInput schema / properties / category / enum

Previous value: -[
-  "devtools",
-  "ai",
-  "games",
-  "productivity",
-  "design",
-  "social",
-  "data",
-  "creative",
-  "other"
-]New value: +[
+  "ai",
+  "creative",
+  "data",
+  "design",
+  "devtools",
+  "games",
+  "productivity",
+  "social",
+  "other"
+]

addedInput schema / properties / handle
```
Added value: +{
+  "type": "string"
+}
```

removedInput schema / properties / hero_image_url

Removed value: -{
-  "description": "Optional public http(s) hero image URL.",
-  "maxLength": 2048,
-  "type": "string"
-}

changedInput schema / properties / pitch / description

Previous value: -"One-line pitch (what it is, who it's for)."New value: +"One line on what it does, up to 140 characters"

removedInput schema / properties / pitch / maxLength
```
Removed value: -200
```
removedInput schema / properties / pitch / minLength
```
Removed value: -1
```

changedInput schema / properties / repo_url / description

Previous value: -"Optional http(s) source-repo URL."New value: +"Source repository, if public"

removedInput schema / properties / repo_url / maxLength
```
Removed value: -2048
```

changedInput schema / properties / title / description

Previous value: -"Project name."New value: +"App name, up to 60 characters"

removedInput schema / properties / title / maxLength
```
Removed value: -100
```
removedInput schema / properties / title / minLength
```
Removed value: -1
```

changedInput schema / properties / url / description

Previous value: -"Public http(s) URL where people can try it."New value: +"Where to try it (https)"

removedInput schema / properties / url / maxLength
```
Removed value: -2048
```
removedInput schema / properties / url / minLength
```
Removed value: -1
```
addedInput schema / properties / workspace
```
Added value: +{
+  "type": "string"
+}
```

Changedunlike_project3 fields changed
- removedInput schema / $schema
```
Removed value: -"http://json-schema.org/draft-07/schema#"
```
- removedInput schema / properties / project_id / description
```
Removed value: -"Project id or slug to unlike."
```
- removedInput schema / properties / project_id / minLength
```
Removed value: -1
```
Addedupdate_project
Removedwallet_balance

1 tool updateSep 9, 2026

Changedlist_projects1 field changed

addedInput schema / properties / offset

Added value: +{
+  "description": "Zero-based offset (default 0, max 1000000). Pass pagination.next_offset to continue the same query.",
+  "maximum": 1000000,
+  "minimum": 0,
+  "type": "integer"
+}

5 tool updatesJul 24, 2026
- Changedadd_review1 field changed
  - addedInput schema / properties / body / maxLength
```
Added value: +10000
```
- Changedget_project1 field changed
  - addedInput schema / properties / id_or_slug / maxLength
```
Added value: +200
```
- Changedlist_projects1 field changed
  - addedInput schema / properties / query / maxLength
```
Added value: +100
```
- Changedreply_to_review1 field changed
  - addedInput schema / properties / body / maxLength
```
Added value: +10000
```
- Changedship_project6 fields changed
  - addedInput schema / properties / body_md / maxLength
```
Added value: +20000
```
  - addedInput schema / properties / hero_image_url / maxLength
```
Added value: +2048
```
  - addedInput schema / properties / pitch / maxLength
```
Added value: +200
```
  - addedInput schema / properties / repo_url / maxLength
```
Added value: +2048
```
  - addedInput schema / properties / title / maxLength
```
Added value: +100
```
  - addedInput schema / properties / url / maxLength
```
Added value: +2048
```
1 tool updateJul 13, 2026
- Addedreply_to_review
8 tool updatesJul 2, 2026
- First observedadd_review
- First observedfund_review_bounty
- First observedget_project
- First observedlike_project
- First observedlist_projects
- First observedship_project
- First observedunlike_project
- First observedwallet_balance

Related MCP Connectors

Basemodo
com.basemodo
Deploy, share and run the Apps you build with AI, private to the people you invite.
Cloud Platforms Developer Tools CI/CD & DevOps
1
https://mcp.basemodo.com
Apple Developer MCP by Nova (CIVAI)C
co.civai.nova
Ship a new iOS app from chat. AI runs App Store Connect, builds, release, and submission through Ap…
Developer Tools CI/CD & DevOps
551
https://nova.civai.co/mcp/agents/mcp-apple_developer
SecondPage
cc.secondpage
Dashboards, websites, and apps: the Google Drive for everything your AI makes. Edit it together.
Cloud Storage Workplace & Productivity Content Management Systems
1
https://mcp.secondpage.cc/mcp
Kaito Query Service
io.github.TheSandemon
AI LLM with Gemini, MiniMax, Replicate, OpenRouter. Vision, search, code review. USDC on Base.
Search Blockchain
2
https://us-central1-sand-gallery-lab.cloudfunctions.net/toolsCall

Related MCP Servers

Ship Receipt
Image & Video Processing Data Visualization
kdnsue
A
license
Not graded
quality
C
maintenance
Lets AI assistants generate Ship Receipt PNG receipts (project stats, revenue, cost, verdict) for indie makers.
Updated 3 days ago (2026-11-06 09:19 UTC)
2
MIT
kylrixofficial
Workplace & Productivity Note Taking Project Management
Kylrix
A
license
Not graded
quality
A
maintenance
Build, ship and think in one living agentic workspace
Updated 2 days ago (2026-11-07 04:40 UTC)
15
AGPL 3.0
Waypoint
Developer Tools Knowledge & Memory Project Management
STiFLeR7
A
license
A
quality
B
maintenance
Enables AI coding tools to share one Markdown ship's log per project, so each session can read the current state, recent work and next steps across Claude Code, Codex, Gemini CLI and Copilot CLI, plus a dashboard showing every project at once. It also flags sessions that did work but logged nothing, and can be exposed remotely to ChatGPT via a self-hosted beacon.
Updated 12 days ago (2026-10-28 10:29 UTC)
5
180 PyPI
Apache 2.0
lavela
Cloud Platforms CI/CD & DevOps Developer Tools
ym2629
A
license
Not graded
quality
C
maintenance
Enables AI agents to build and deploy an app from a GitHub repository to a managed live server and then operate it — logs, captured errors, health checks, managed Postgres, secrets, custom domains, email authentication, and Stripe checkout links. It also exposes safe, read/write-labelled tools so agents can rebuild, start/stop, and inspect projects without ever editing source code.
Updated 20 days ago (2026-10-20 18:14 UTC)
MIT