AI agents are becoming increasingly autonomous. They need to integrate with the broader digital environment and it seems that this will only grow more true over time.
The Model Context Protocol standard was developed to enable that. It allows developers to expose functionality in the form of MCP servers, and AI agents to make use of those servers to interact with various existing third-party services.
But wait, we already had good, rich, and widely adopted standards and conventions for machine-to-machine communication in the form of RESTful APIs built on top of HTTP. Why did we need another standard?
Letting AI agents directly use existing APIs had a number of disadvantages at first:
- It’s a relatively low-level form of access which made it more challenging for agents to come up with the right invocations for a given task.
- Agents didn’t know the details of individual APIs.
- People rightfully didn’t want to make API keys part of their prompts.
With LLM and agent capabilities steadily getting better, #1 has empirically stopped being an issue in practice. If anything, the increased flexibility that comes with lower-level primitives plays to the strengths of today’s models.
Similarly, agents now routinely search the web, which means they can usually find the latest documentation for any public API.
This leaves us with #3. How can we let agents use HTTP APIs with minimal overhead and without worrying about authentication?
A fresh take: Latchkey
Agents are already very good at using curl to access HTTP APIs. Language models have been trained on tons of examples of curl invocations and many API docs use the curl format for examples.
So what if agents simply used plain old curl calls that they know so well, and another tool took care of adding authentication on the fly?
That’s exactly what our tool Latchkey does. It allows agents to simply call APIs by prepending their curl invocations with the latchkey command:
latchkey curl -X GET https://gitlab.com/api/v4/user
Latchkey then adds the necessary credentials in the form of curl arguments, passes all the arguments to an actual curl process, and returns its output to the caller.
How does it know about the credentials? Users can store them manually in advance, using curl-like syntax, like this:
latchkey auth set gitlab -H "PRIVATE-TOKEN: <token>"
There are more options, including an experimental functionality where the agent can open a browser window and ask the user to log in first. I won’t list them all here; take a look at the docs for the full picture.
The point is: say no to unnecessary complexity. There’s no need to go through intermediaries. Let’s keep things transparent and simple.
We continue to improve Latchkey. We invite you to try it out - it’s free and open-source (MIT-licensed). Contributions and feedback are very welcome!
Demo
See an OpenCode agent use Latchkey to:
- Discover an available API (AWS).
- Confirm authentication.
- Use the API to answer a practical question about spending.
Follow along with our builds! Subscribe to Imbue’s email newsletter for product updates and events.