An agent host may need a connection it can configure. An application developer may need a library to import into code. Those requirements lead to different integration surfaces.

## What does each provide to its caller?

An MCP server provides a protocol interface; an SDK provides functions and types for a programming language.

The [MCP architecture guide](https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture) describes servers exposing capabilities to connected clients. A server can run as a local process or provide a remote endpoint.

| Interface  | Caller                                        | What the caller uses                          | Runtime responsibility                                       |
| ---------- | --------------------------------------------- | --------------------------------------------- | ------------------------------------------------------------ |
| MCP server | An MCP client in an agent host or application | Protocol requests and discovered capabilities | Someone runs the server process or remote service            |
| API SDK    | Application code                              | Library methods that call an API              | The application runs the library and manages its integration |
| MCP SDK    | Code implementing an MCP client or server     | Protocol types and implementation helpers     | The application still runs the resulting client or server    |

An SDK package does not become a running server merely because you install it.

## Can a server use an SDK?

Yes. A developer can use a protocol SDK to implement an MCP server, then use another client library inside its handlers.

The [MCP SDK documentation](https://modelcontextprotocol.io/docs/2026-07-28/sdk) describes libraries for building clients and servers. Here, SDK identifies code used to implement the protocol.

An API SDK has a different target: it calls a service's API. A hypothetical order server could expose an order-status tool whose handler uses an API SDK to retrieve the order.

The outer MCP interface and the inner API call have separate contracts. Supporting an API operation does not automatically expose it as an MCP tool.

## Which responsibilities remain in my application?

Your application still decides which operations to request. It also decides how to handle their results.

With an API SDK, your code selects a method and supplies its arguments. With MCP, the host routes requests through a client to the server's exposed capabilities.

The [MCP architecture](https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture) leaves the host's use of model context outside the protocol's scope. A tool connection does not decide your business rules, authorization policy or completion criteria.

For an order lookup, receiving the requested status may finish the task. For sending a message, submission and later delivery are separate outcomes.

## How do I choose a Bird integration?

You can connect a compatible agent host to [Bird's MCP server](/docs/ai/mcp-server), or integrate application code through an API client.

For the library route, the [Bird SDK decision](/explained/platform/should-i-use-an-sdk-or-call-the-api-directly) covers the choice between an SDK and direct HTTP. For the tool route, your client's Bird inventory supplies the available tool names and input schemas.

Compare the operation you need on the interface you intend to use. An operation's presence in one interface does not establish its presence in another.

1. Use the MCP connection when your host needs to discover and invoke Bird tools.
2. Use an API client when your application code selects and invokes the service operations.
3. Use an MCP SDK when you are implementing the protocol client or server itself.

## Related resources

- [Send your first email](/docs/get-started/send-your-first-email) (docs)
- [Build your first integration](/learn/paths/integration) (course)

[Get an implementation brief](/learn/workspace?topic=api-basics)