Speakeasy | San Francisco or London | https://www.speakeasy.com/

At Speakeasy we craft developer experiences with care for our customers. We have a suite of products focused on helping team's distribute their products. We build: - An API platform that helps teams generate and maintain high quality SDKs, Terraform Providers and CLIs for their users by leveraging OpenAPI. The complete platform is usable as a set of claude skills. - A MCP Platform that helps teams distribute their product capabilities directly to coding agents, through chat and other agentic experiences.

We are a high agency team of senior developers with a passion for solving hard technical problems so our customers don't have to. Much of what we do is open source. Check out our github to get a sense of our tech: https://github.com/speakeasy-api

Roles: - Product Engineers for our Gram, our MCP Platform - Go, Typescript, MCP protocol, Serverless infrastructure - Product Engineers for our Code Generator - Go, Typescript, Linters, Compilers, OpenAPI, Code generation

Contact: hiring@speakeasy.com

I feel the CLI vs MCP debate is an apples to oranges framing. When you're using claude you can watch it using CLI's, running brew, mise, lots of jq but what about when you've built an agent that needs to work through a complicated API? You don't want to make 5 CRUD calls to get the right answer. A curated MCP tool ensures it can determinism where it matters most.. when interacting with customer data

Sounds more like a problem with your APIs trying to follow some REST 'purity' rather than be usable.

Even in the case where you need to group steps together in a deterministic manner, you don't need an MCP server for that. You just need to bundle those steps into a CLI or API endpoint.

That was my point. Going the extra step and wrapping it in an MCP provides minimal advantage vs. just writing a SKILL.md for a CLI or API endpoint.

Hey HN, Sagar co-founder & CEO of Speakeasy here! We built Gram because we kept seeing the same problem: developers spinning up MCP servers that technically work but practically confuse agents.

We think the solution is good tool design and so we've created Gram to help. It uses existing APIs as starting point, and makes adding rich descriptions, and curating workflow-based tools easy. It handles the hosting, infra and authentication so that your team can stay focused on what's important.

This is our first big open source project, so we appreciate everyone taking a look. Please don't hesitate to drop feedback here, or email me directly at sagar@speakeasy.com if you have anything that you'd rather share privately!

Congrats on the launch! This is really exciting and seems like an obvious progression on how companies can expose their event streams. Interfaces like kafka are so ubiquitous compared to webhooks. This seems to build on that with infrastructure to take care of all the failure points and tough devex. Anyone who's worked with webhooks knows how common failures are!

A big +1 on the Kafka destination type being a priority. Thanks!

Companies hosting their API specs publicly is a great move but I think SDKs not officially maintained and endorsed by the company always suffer from lack of upkeep which eventually makes them more of headache to use than just hitting the API directly.

Check out https://www.speakeasy.com/. We generate fully type-safe SDK from OpenAPI and for our TS offering we delegate the type checking to Zod.

Definitely Terraform for me: - Vendor agnostic but you do have to write separate code per vendor - Better state management capabilities - Fastest growing dev community in IAC space (except for maybe Pulumi?) - I don't know the current state of CDK but last year imports weren't really supported so there was no way to reconcile state with existing hand rolled infra. Speaks to TF's drift detection being a core capability.

> Vendor agnostic but you do have to write separate code per vendor

wat

as opposed to using a different set of tool AND THEN write separate code for each vendor

That isn't vendor agnostic.

vendor agnostic doesn't exist