This lets me add quick skills that are essentially just: “this is the OAS link, this is how you store and use the authorization, this is when I want you to use it”. That combined with pointing it at the documentation for common workflows and usage examples, and it’s been great.

The only thing I’ve had trouble with is auth really. MCPs are treated as first class citizens by most model provider’s agents and trying to provide a shell-based alternative for hiding the secret credentials from the LLM has been difficult.

https://github.com/turlockmike/murl

which lets users create collections of any publicly available tool which let's us do awesome things

We can auto generate a skills.md for collections https://tpmjs.com/ajax/collections/unsandbox/skills.md (https://tpmjs.com/ajax/collections/unsandbox to see the collection)

We analyze all the tools source code to write the skills.md using LLM's and then we auto inject three different ways agents can iteract with them

- hosted mcp servers for collections automatically e.g. https://tpmjs.com/api/mcp/ajax/unsandbox/sse

- a cli tool that can invoke each tool in the collection e.g. tpm run --collection ajax/unsandbox --tool [tool-name] --args '{"key": "value"}'

- restful endpoints for direct execution of tools e.g. curl -X POST https://tpmjs.com/api/mcp/ajax/unsandbox/http

It's very much alpha, but after building this, I don't see why you can't let agents choose any method they want of interacting with your service.

It means your agents can use CLI, MCP or REST, only in one style or any style all at once.

The next frontier is using hooks to guide agents to use tools better and avoid doom loops.

auth considerations are present in the design of MCP. this, as opposed to the hodgepodge auth story with CLIs. there are APIs that either don't support OAuth or where using bare credentials is more expedient, and using agent-visible env vars is a security incident waiting to happen. but that doesn't necessarily mean we must use MCP. i think it's a matter of time before agentic tools come bundled with a proxy layer from which secrets / env vars can be set and used but not directly read [0].

[0] https://www.joinformal.com/blog/using-proxies-to-hide-secret...

Our approach is slightly more complex because we need to supported fully authenticated sessions for end users and for shared credentials. It works by creating scoped API tokens to our service which get bundled into dynamically generated CLI clients. We point the agent to the client and voila. The agent can now run `some-command list-gmail-messages --query "tom"`. The oauth complexities, credential lifecycle and everything is handled automatically by the platform on the fly - it does not matter if the user is on Slack or access the agent through some chat interface or if the agent runs in the background doing work. It just works!

The points made in the article can be included in the design choices.