How to Create Claude Connectors for Your Tools

A Claude connector is an MCP server: a small program that exposes a set of tools through the Model Context Protocol, which Claude can then call in a session. Building one requires defining the tool interface, writing the server logic, handling authentication and testing the connection end to end.

Tools like fenbs keep the interface decisions, source documentation links and implementation tasks in one place across the build, so the next session starts from where the last one stopped rather than having to re-read the whole codebase.

What you are building

An MCP server communicates with an AI client over stdio or HTTP. The client asks the server what tools are available; the server returns a list of tool names and descriptions. The client can then call a tool with arguments, and the server returns the result.

For most developer-built connectors, stdio transport (standard input/output) is the simplest starting point. The AI client spawns the server as a child process and communicates through its stdin and stdout. HTTP transport is better for servers that run persistently or serve multiple clients.

Anthropic publishes MCP SDKs for TypeScript and Python. The TypeScript SDK is at @modelcontextprotocol/sdk on npm; the Python SDK is mcp on PyPI. Both provide the base server class, tool registration helpers and the request/response types.

Step 1: Define the tool interface

Before writing any code, define what the tools do. Each tool needs a name, a plain-language description and a JSON Schema for its input parameters. The description is what the AI reads to decide whether to call the tool, so it matters more than most function documentation you write for other developers.

Write descriptions that say what the tool does and when to use it, not just the parameter names. A tool described as "search_docs: searches documents" is harder for the model to use correctly than "search_docs: searches the internal documentation library and returns the top three matching sections with titles and page references."

Keep tools small and specific. A tool that does one thing is easier for the model to call correctly than a general-purpose tool with many optional parameters. If your use case requires ten capabilities, ten specific tools are usually better than one flexible tool.

Step 2: Write the server

With the interface defined, write the server code. In TypeScript with the MCP SDK, you create a Server instance, register each tool with its schema and a handler function, then connect the server to a transport. The handler receives the tool arguments, calls your underlying API or service, and returns the result.

import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';

const server = new Server(
  { name: 'my-tool-server', version: '1.0.0' },
  { capabilities: { tools: {} } }
);

server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [{ name: 'get_item', description: 'Gets an item by ID', inputSchema: { ... } }]
}));

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  // call your service here
  return { content: [{ type: 'text', text: result }] };
});

const transport = new StdioServerTransport();
await server.connect(transport);

The Anthropic MCP documentation covers the full API surface, error handling patterns and result types. Read the spec before implementing edge cases; the return format for errors differs from successful results and the client handles them differently.

Keep the server's dependencies minimal. A server that requires dozens of packages to start adds startup latency and more surface area for version conflicts. Install only what the tool handlers actually need, and test the server cold after clearing any package caches to confirm it starts cleanly.

Step 3: Handle authentication

If the tools your server exposes require credentials (an API key, an OAuth token, a database password), pass them through environment variables rather than hardcoding them. The Claude Desktop config file accepts an env object per server where you set the variables the server process needs.

Do not put credentials in the tool descriptions or in tool arguments. A credential in a tool argument can end up in the AI's context window and potentially in logs. Environment variables are the standard and safe place for secrets in a process.

Step 4: Test the connection

Add the server to Claude Desktop's config file, enable developer mode and restart the app. In the connected tools panel, confirm the server is listed and the tools appear with their descriptions. Ask Claude to call one of the tools with a simple, known input and verify the result.

Test error paths too. Pass an invalid argument, an out-of-range ID or a request that should be refused. Confirm that the server returns a useful error message rather than crashing. The AI uses the error message to explain what went wrong; a generic "error" is not helpful.

How to do this with fenbs

1. Create a free account and add a project for the connector build.
2. Add the tool definitions as tasks in fenbs: one task per tool, with the name, description and parameter schema as the task description.
3. Link the upstream API documentation in fenbs as links so any session working on the build can find them quickly.
4. Connect Claude from Integrations and ask it to read the project context before starting each coding session.
5. Record interface decisions as Decisions in fenbs: why a tool is scoped a particular way, the chosen authentication method and any tradeoffs. Those decisions are visible to every future session on the project.

fenbs does not build or host MCP servers. It keeps the project context for the build organized and accessible.