MCP API Integrations

1. MCP API Integrations

In this video, we'll deep-dive into API integration for our MCP servers.

2. Recap: The convert_timezone() Tool

Quick reminder of where we left off. In chapter one, we built a convert_timezone tool that sends a request to the OpenTimezone API with a JSON payload, pulls the converted time from the response, and returns a friendly string. In this video, we'll harden this pattern for production.

3. API Improvements

We'll implement

4. API Improvements

a timeout period and more robust error handling to minimize disruption and keep our users informed. Additionally, external APIs used in MCP servers often require

5. API Improvements

authentication. We'll talk more about how to handle personal API credentials, and how to set up MCP servers to handle authentication. Let's start with timeouts and error handling!

6. Timeout and Error Handling

At the top we build the payload the same way as before—dateTime, fromTimezone, and toTimezone in a dictionary that we'll send as JSON. The important change is with the try-except block. We call requests.post with the URL, the JSON payload, and timeout=10. That timeout means: if the server doesn't respond within ten seconds, requests will raise an exception instead of hanging. In production you don't want a tool call to block indefinitely; ten seconds is a reasonable upper bound for most API calls. Next we call raise_for_status(). That checks the status code from the request; if it's unsuccessful, it raises an exception. If it's successful, we parse the JSON, pull out the converted time with data.get(), and return the formatted string If anything goes wrong—a timeout, a connection error, or a bad status code—we land in the except block. The LLM and the user then see a descriptive error instead of a raw traceback. That keeps the tool predictable and reliable in production.

7. API Authentication: The Do's and Don'ts

When MCP servers call an external API that requires authentication, the API key should live only on the server-side.

8. API Authentication: The Do's and Don'ts

For a local host, we might set the key using an environment variable or store it in a .env file that the server loads at startup.

9. API Authentication: The Do's and Don'ts

When deploying to a remote host, such as a virtual machine, container, or cloud platform, we configure the key there as an environment variable or managed secret.

10. API Authentication: The Do's and Don'ts

In every case, the key stays on the server-side. The client never sends it, never receives it, and never has access to it. The client only calls tools and receives their results.

11. API Authentication: The Do's and Don'ts

When making a request to the external API, the server reads the key from the environment and attaches it to the outbound request, typically in a standardized header. The key should never be hardcoded in source code, accepted as a tool argument, returned in a tool result, placed in a URL, or written to logs. This ensures the key is only shared between the server and the external API. Let's add this to our server!

12. MCP Server API Authentication

In the code, the tool signature and payload remain the same. The new addition is the headers configuration. The server sets "Content-Type": "application/json" and then reads the key using the os module. If the key is present, it adds an Authorization header with the Bearer token. If the API requires a key and it's missing, the server should return a clear error message. If the API does not require authentication, the header can simply be omitted, allowing the same code to work for both protected and open APIs. This code now reflects a production-ready pattern that combines explicit timeouts, structured error handling, and secure authentication.

13. Let's practice!

Time to give this a go!

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.