> ## Documentation Index
> Fetch the complete documentation index at: https://www.wirebase.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Build an MCP connector

> Expose your own API to Wirebase as tools by running a remote MCP server.

## Overview

Wirebase is an MCP **client**. Any remote server that speaks the [Model Context Protocol](https://modelcontextprotocol.io) can be added as a [connector](/docs/user-guide/workspace/connectors), and its tools become available in chat, agents and workflows.

## Requirements

| Requirement | Details |
| - | - |
| **Transport** | Streamable HTTP (recommended) or SSE. Wirebase tries Streamable HTTP first and falls back to SSE. |
| **Reachability** | A public `https://` URL Wirebase can reach. Local (stdio) servers aren't supported. |
| **Capabilities** | Tools. Each tool needs a name, a description and a JSON Schema for its input. |

## Authentication

Choose one:

<Tabs>
  <Tab title="Static header">
    Accept a token in a header, typically `Authorization: Bearer <token>`. The person adding the connector enters it under **Headers**.
  </Tab>

  <Tab title="OAuth">
    Implement the MCP authorization spec (OAuth 2.1 with PKCE). Wirebase discovers your authorization server from the MCP server's metadata and registers itself with dynamic client registration:

    | Client metadata | Value |
    | - | - |
    | `client_name` | `wirebase-<connector-name>` |
    | `redirect_uris` | `https://www.wirebase.com/api/mcp/oauth/callback` |
    | `grant_types` | `authorization_code`, `refresh_token` |
    | `token_endpoint_auth_method` | `none` (public client, PKCE) |
    | `scope` | `mcp:tools` |

    Users click **Authorize** and complete sign-in in a popup. Tokens are encrypted at rest and refreshed automatically. By default each user authorizes separately; the connector's owner can turn on **Shared Authentication** instead.
  </Tab>
</Tabs>

## Tool naming

Tools appear in Wirebase as `<connector>_<tool>`, for example `github_create_issue`. Names are sanitized to letters, numbers, underscores and hyphens and capped at 124 characters. Keep tool names short and descriptive.

## Write tools that models use well

* **Describe when to use the tool**, not just what it does. The description is what the model reads when deciding.
* **Keep input schemas small and typed.** Use enums for fixed choices and mark required fields.
* **Return compact results.** Tool output is truncated at about 40,000 characters before it reaches the model. Return the fields that matter, and paginate large lists.
* **Return clear errors.** A short, specific error message lets the model correct itself and retry.

Admins can add per-tool and per-connector [custom instructions](/docs/user-guide/workspace/connectors#customize-how-tools-are-used) to steer usage without changing your server.

## Test your server

Add it under **Workspace → Connectors → Add custom connector**, open it, and use **Tools Test** to call each tool with sample input before using it in chat.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.