This server is a Model Context Protocol (MCP) server that gives AI assistants access to Capawesome documentation and, with an API token, the Capawesome Cloud management API.
Search documentation (search_docs): Search Capawesome docs, guides, and blog by keyword, optionally restricted to SDKs, Cloud, Insiders, or blog sections.
Read documentation pages (get_doc_page): Fetch the full markdown of any Capawesome documentation or blog page by URL or path.
List recent blog posts (list_blog_posts): Get the 20 newest Capawesome blog posts, useful for releases, announcements, and deprecations.
Cloud management API tools (cloud_*): When configured with an API token, manage Capawesome Cloud resources — apps, builds, channels, deployments, and more.
Flexible deployment: Use the hosted HTTP endpoint or run locally via npx with options for token, toolsets, and read-only mode.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Capawesome MCP Server List my Capawesome Cloud apps"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The official MCP server for Capawesome. It gives AI assistants the current Capawesome documentation — plugins, Capawesome Cloud, Capawesome Insiders and the CLI — and, with an API token, the Capawesome Cloud management API for apps, channels, builds, deployments and more.
Maintained by Capawesome.
The server is hosted and ready to use:
https://mcp.capawesome.io/mcpThe documentation tools need no account and no token. The Capawesome Cloud tools are only available when the request carries an API token — see Authentication.
Related MCP server: expo-mcp
For the documentation tools, no token is needed:
claude mcp add --transport http capawesome https://mcp.capawesome.io/mcpTo add the Capawesome Cloud tools, pass your API token as a bearer header and select the toolsets:
claude mcp add --transport http capawesome "https://mcp.capawesome.io/mcp?toolsets=all" \
--header "Authorization: Bearer YOUR_TOKEN"Go to Settings → Connectors → Add custom connector and enter:
Name: Capawesome
URL: https://mcp.capawesome.io/mcp
Or add .cursor/mcp.json to your project:
{
"mcpServers": {
"capawesome": {
"url": "https://mcp.capawesome.io/mcp"
}
}
}Or add .vscode/mcp.json to your project:
{
"servers": {
"capawesome": {
"type": "http",
"url": "https://mcp.capawesome.io/mcp"
}
}
}Add the server to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"capawesome": {
"serverUrl": "https://mcp.capawesome.io/mcp"
}
}
}Add the server to your Zed settings.json:
{
"context_servers": {
"capawesome": {
"url": "https://mcp.capawesome.io/mcp"
}
}
}Clients that cannot connect to a remote server over HTTP can run this package, which proxies stdio to the hosted server:
{
"mcpServers": {
"capawesome": {
"command": "npx",
"args": ["-y", "@capawesome/mcp"],
"env": {
"CAPAWESOME_TOKEN": "your-token"
}
}
}
}Requires Node.js 22 or later. Omit env to use the documentation tools only.
Create an API token in the Capawesome Cloud Console and pass it to the server.
When connecting over HTTP, send it as an Authorization: Bearer <token> header. When running this package, set the CAPAWESOME_TOKEN environment variable and the proxy sends the header for you.
Without a token, only the documentation tools are registered — the Capawesome Cloud tools are absent, not merely hidden.
These environment variables configure the proxy. They apply to this package only; over HTTP, use the equivalent header and query parameters.
Variable | Purpose |
| API token, sent as |
| Comma-separated toolsets to register, sent as |
| Set to |
| Override the endpoint. For development only. |
The server exposes the documentation tools (search_docs, get_doc_page, list_blog_posts) plus the cloud_* tools for the Capawesome Cloud management API, grouped into toolsets.
See the MCP documentation for the full tool and toolset reference.
The endpoint is limited to 100 requests per minute per IP. Requests over the limit are answered with 429 Too Many Requests; retry after a short wait.
Your IP address is processed for rate limiting only. Queries and tool arguments are not stored, not logged beyond Cloudflare's standard edge logs, and never used for training. Your API token is used to authenticate against the Capawesome Cloud API on your behalf and is not stored by the server. See the Privacy Policy for details.
Capacitor MCP Server — unofficial MCP server for the Capacitor documentation, plugin list and blog.
Ionic Framework MCP Server — unofficial MCP server for the Ionic Framework documentation, components and usage examples.
Capawesome Cloud Live Updates — ship JavaScript, HTML and CSS changes to your app without an app store review.
Capawesome Cloud Native Builds — build native iOS and Android apps in the cloud, without a Mac.
Capawesome Cloud App Store Publishing — submit builds to the Apple App Store and Google Play Store.
npm install
npm run build
npm testSet CAPAWESOME_MCP_URL to point the proxy at a local server instead of the hosted one:
CAPAWESOME_MCP_URL=http://localhost:8787/mcp node dist/index.jsReleases are managed by release-please. Merging its release pull request tags the version, publishes the package to npm and then publishes server.json to the MCP Registry. The version in server.json is bumped by release-please together with package.json, so it never has to be edited by hand. To publish to the registry manually, install mcp-publisher, run mcp-publisher login dns --domain=capawesome.io --private-key=<key> with the Ed25519 private key from the password manager and then mcp-publisher publish.
See LICENSE.
Read the full source markdown of a Capawesome documentation or blog page. Use this after search_docs to read a page end to end before writing code against a plugin API, a CLI command or a Capawesome Cloud workflow — snippets from search results are deliberately short and regularly omit required configuration steps. Returns the page title, its URL and the page markdown including code samples, as it is authored but without the build metadata. Do not use this to find a page: it needs the exact URL or path, so run search_docs (or list_blog_posts for articles) first. Do not use it for pages outside capawesome.io.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page URL or site-relative path, e.g. "https://capawesome.io/docs/cloud/live-updates/" or "cloud/live-updates/". Anchors are ignored; the whole page is returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description reveals important behaviors: it returns title, URL, and markdown (excluding build metadata), ignores anchors, returns the whole page, and requires an exact URL/path. This exceeds what annotations alone convey.
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 somewhat verbose but every sentence carries essential guidance (usage, return format, limitations, sibling differentiation). No fluff or redundancy; the structure flows logically from purpose to usage to caveats.
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's simplicity, the description covers all needed context: what it returns, when to call it, what not to do, and domain restrictions. There is no output schema, but the return content is described sufficiently. It fully equips an agent to use the tool correctly.
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 schema has 100% coverage for the single 'url' parameter, and the description enhances it with concrete examples (both full URL and relative path) and clarifies that anchors are ignored and the entire page is returned. This adds significant semantic value.
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 explicitly states the tool reads the full source markdown of a Capawesome documentation or blog page, and clearly distinguishes itself from sibling tools by specifying its role as a follow-up to search_docs and not a finder.
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 provides explicit when-to-use and when-not-to-use guidance: use after search_docs for full page content, use search_docs or list_blog_posts for discovery, and avoid pages outside capawesome.io. No ambiguity remains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the 20 most recent posts from the Capawesome blog, newest first. Use this when the question is about what is new — recent releases, announcements, monthly updates, deprecations or newly published guides. Returns title, description, date, categories and url per post; pass a url to get_doc_page to read the whole article. Do not use this to answer a topic question: the feed only carries the newest posts, so search the documentation and the blog archive with search_docs instead.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds valuable behavioral context: the exact limit (20), ordering (newest first), return fields (title, description, date, categories, url), and the implication that it returns snippets (not full articles) by directing to get_doc_page. This goes beyond the annotations without contradicting them.
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 compact and front-loaded: it states the core action first, then usage conditions, then return format, then a negative usage note. Every sentence earns its place, with no redundancy or fluff.
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 zero parameters and no output schema, the description is fully sufficient. It specifies the result set size, ordering, fields returned, how to access full content (via get_doc_page), and when to avoid this tool. An agent has everything needed to decide whether and how to call it correctly.
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 tool has zero parameters, so the baseline is 4. The description correctly doesn't attempt to explain parameters since none exist, and it implicitly conveys that no arguments are needed by stating the action without any prerequisites. This is appropriate for a parameterless tool.
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 explicitly states the verb, resource, and limit: 'List the 20 most recent posts from the Capawesome blog, newest first.' It also differentiates from siblings by specifying when to use it (recent releases, announcements, etc.) and when not to (topic questions), making the tool's purpose unmistakable.
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?
Clear guidance on when to use: 'Use this when the question is about what is new...' and explicit exclusion: 'Do not use this to answer a topic question...' It also names the alternative `search_docs` and explains the reason (feed only has newest posts). Additionally, it routes the agent to `get_doc_page` for full articles, covering the full usage path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Capawesome documentation, guides and blog by keyword. Use this first for any question about Capawesome SDKs (Capacitor and Cordova plugins such as Live Update, NFC, Biometrics), Capawesome Cloud (live updates, native builds, app store publishing, automations), Capawesome Insiders or the Capawesome CLI — the answer is almost always documented, and guessing plugin APIs or CLI flags produces broken code. Returns the best matching page sections with title, url, snippet, section and, for a hit inside a page, the parentTitle and parentUrl of that page. The same results are attached as structured content. Do not use this to read a full page: call get_doc_page with a url from these results. Do not use it to browse recent announcements or release notes: use list_blog_posts. Do not use it for anything about a concrete app, build, channel or deployment in Capawesome Cloud: those live behind the cloud_* tools.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | The maximum number of results to return, e.g. 5. Defaults to 10, maximum 25. | |
| query | Yes | The search terms, e.g. "live update rollback" or "biometrics android setup". Plain keywords work best; no search operators are supported. | |
| section | No | Restrict the search to one part of the documentation: "sdks" (plugin references and guides), "cloud" (Capawesome Cloud), "insiders" (Capawesome Insiders) or "blog" (articles and release notes). Defaults to searching everything. |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds useful behavioral context by describing the return shape, best-matching section behavior, and that results are also attached as structured content. There is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average, but every sentence earns its place: it front-loads the purpose, then covers return behavior, structured content, and explicit alternatives/exclusions. No filler or redundancy.
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?
The tool has an output schema, full parameter schema coverage, and annotations; the description completes the picture with usage guidance, boundaries, alternatives, and return-field details. Nothing an agent needs to invoke it correctly is missing.
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?
Schema coverage is 100% and every parameter already has a clear description, including examples and enum values. The description mostly reinforces the keyword-based scope rather than adding new parameter-level meaning, so baseline 3 is appropriate.
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?
States a specific verb and resource: searching Capawesome documentation, guides, and blog by keyword. It clearly distinguishes itself from siblings by naming get_doc_page and list_blog_posts and by excluding cloud_* tools.
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?
Explicitly says 'Use this first' for documentation questions and provides concrete when-not-to-use guidance, including alternatives such as get_doc_page and list_blog_posts. The description fully routes an agent to the correct tool for each scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.0.1get_doc_pagelist_blog_postssearch_docsScored across 3 tools
Each tool has a clearly distinct job: search_docs finds relevant pages by keyword, get_doc_page retrieves the full content of a known URL, and list_blog_posts surfaces recent blog posts. The descriptions explicitly cross-reference each other to prevent confusion, so an agent should not struggle to pick the right one.
All tool names follow the same verb_noun snake_case pattern: search_docs, get_doc_page, and list_blog_posts. The verbs (search, get, list) and nouns (docs, doc_page, blog_posts) align with each tool's function, making the naming predictable and readable.
Three tools is a well-scoped set for a documentation/blog access server: one for discovery, one for retrieval, and one for recency browsing. Each tool earns its place, and the count is within the typical 3-15 range for a focused server.
The set covers the core documentation workflow completely: search_docs finds content, get_doc_page reads full pages, and list_blog_posts handles recent announcements. The only minor gap is that list_blog_posts has no pagination beyond the 20 most recent posts, though search_docs can still locate older content.
Your Expo and EAS project in natural language: up to date SDK docs, cloud builds (status, logs, trig
Deploy and manage your apps, databases, storage, and scheduled jobs from your AI agent
Query your team's drift, vulnerability, and upgrade data from any AI assistant. OAuth 2.1, 51 tools.
Connect an AI assistant to a Capacities space (objects, daily notes, search).
