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

# MCP server

> Nylon as tools an AI agent can call, over the Model Context Protocol.

The Nylon MCP server exposes publishing, connected accounts and network capabilities as tools an [MCP](https://modelcontextprotocol.io) client can call. Point Claude, Cursor, ChatGPT or your own agent at it with a Nylon API key, and the agent works against the same contract your backend does.

```json title="mcp.json" theme={null}
{
  "mcpServers": {
    "nylon": {
      "url": "https://mcp.nylon.dev",
      "headers": {
        "Authorization": "Bearer nylon_live_YOUR_API_KEY"
      }
    }
  }
}
```

That is the whole setup. [Connect a client](/mcp/connect) has the per-client version of it.

## What it is

<CardGroup cols={2}>
  <Card title="One endpoint, no session" icon="plug">
    Streamable HTTP at `https://mcp.nylon.dev`. Every call carries its own key and nothing is stored between them, so there is no session to open, keep alive or recover.
  </Card>

  <Card title="Your API key" icon="key-round">
    The same `nylon_live_` key the REST API takes. No OAuth grant against your Nylon login, no second credential to rotate.
  </Card>

  <Card title="Fourteen tools" icon="wrench">
    Publishing, scheduling, profiles, connections, network capabilities and validation. [Every tool](/mcp/tools) is one endpoint.
  </Card>

  <Card title="The same contract" icon="layers">
    Each tool calls the endpoint that implements it. Same validation, same rate limits, same error codes, same line in your request log.
  </Card>
</CardGroup>

## Why it is a thin surface

The tools are not a second implementation of Nylon for agents. `create_post` is `POST /v1/posts` — the tool takes the endpoint's own request schema, hands it to the endpoint's own handler, and returns the endpoint's own response.

That has a consequence worth relying on: anything an agent can do, your backend can do, with identical semantics. An agent that schedules a post and a nightly job in your own code that schedules the same post produce the same row, the same targets and the same errors. When you move a workflow from a conversation into your own code, nothing about it changes except who is calling.

<Note>
  It also means the reference for what a tool accepts is the reference for the endpoint. [Publishing](/publishing) explains how a post is normalised per network; the [API reference](/api-reference) documents every field.
</Note>

## What is not exposed

<CardGroup cols={2}>
  <Card title="Inbox" icon="message-circle" href="/inbox">
    Live on Facebook and Instagram in the product, with no endpoints yet — and so no tools yet.
  </Card>

  <Card title="Analytics" icon="chart-column" href="/analytics">
    In build. Nothing in the API or the MCP server returns analytics data today.
  </Card>
</CardGroup>

## Next

<CardGroup cols={3}>
  <Card title="Connect a client" icon="terminal" href="/mcp/connect">
    Claude, Cursor, VS Code, ChatGPT, or raw JSON-RPC.
  </Card>

  <Card title="Tools" icon="wrench" href="/mcp/tools">
    All fourteen, with their arguments and what they return.
  </Card>

  <Card title="Scope and safety" icon="shield" href="/mcp/safety">
    What a key reaches, what an agent cannot do, and how failures come back.
  </Card>
</CardGroup>


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