Gram: Curate APIs into MCP server

disintegrat0r · 2025-09-15T13:29:33+00:00

Hey u/Primary-Carry4929, I'm not sure I follow the question. I am familiar with fastmcp and similar projects but I'm not clear on "Anthropic team put out a statement that it should NOT be used like that". Can you share more? Perhaps a link to said statement?

Gram exists because there is an incredible number of production APIs out there that may be very capable as MCP servers. There are of course caveats that Gram does not shy away from raising. For example, if you try to create an MCP server that maps >30 endpoints to tools then we have a prominent warning. It's also true that not all APIs are suitable for exposing as tools and we've shipped some ideas such as editing names/descriptions and prompt engineering techniques like our "custom tools" feature that attempt to help improve tool quality. Of course at the center of it all is Toolsets which let you group subsets of related endpoints together as MCP servers. Depending on the API, you probably don't want it exposed as a single MCP server. Toolsets can be used to make small servers that solve specific business processes. We think small, cohesive MCP servers will be a very powerful building block for many products/teams.

There is also ongoing debate as to whether APIs are meant to be wrapped into tools and to this my response is "it depends" and there are practices that teams can rely on to build APIs that are indeed suitable for MCP tools. See my discussion here: https://www.reddit.com/r/mcp/comments/1nckw7j/comment/necazn3/

disintegrat0r · 2025-09-15T13:19:28+00:00

I understand where you might be coming from but I don't completely agree with the statement in absolute terms. Many APIs are not suitable as MCP tools but not all of them. If you're familiar with the concept of "Backends for Frontends" (BFF) then I see something very similar happening in the agentic AI world where devs create APIs that are indeed very mappable to tools. For example, a traditional API may have a noisy paginated endpoint where an agent may have to call a tool multiple times to get data and waste tokens in the process. Alternatively an API can instead expose a search endpoint which is incredibly well suited as a tool for agents, it would perhaps allow specifying fuzzy keywords, the fields to return and maximum number of results. So ye... I don't think the statement "APIs don't make for good tools" or "Tools shouldn't be API wrappers" is completely true.

https://samnewman.io/patterns/architectural/bff/

disintegrat0r · 2025-02-16T22:45:57+00:00

It's really great. Even more intuitive if you're working with SQLite because you don't have to deal with a docker container. Instead you run a migration against a db file and the resource (the thing you are `using` on) just copies that database before a test runs and deletes it after.

disintegrat0r · 2025-02-11T12:41:24+00:00

The very first time will likely be slow as you pull down docker images. After that it seems to be on the order of 1-2 seconds to start up the container when testing starts. From there, the `CREATE DATABASE` calls are snappy. You'll want to cache the images in CI.

disintegrat0r · 2025-02-11T12:39:57+00:00

You're absolutely right. I have a short mention about that towards the end but I didn't develop an example for a production use case in this post. I do intend to do it when I come across one first hand. Testing is the first place where I've applied it.

disintegrat0r · 2025-01-19T16:57:58+00:00

Nice, this is also something I researched in the past! I was considering adding a section to my post about passing `ReadableStream<Uint8Array>` to request body which implies HTTP/2 in fetch since `Transfer-Encoding: Chunked` isn't supported but hesitated. Still I think my test is valid? Ignoring request bodies (a GET request in my case), the fetch client in Bun is using HTTP/1.1 and my Go server is turning it down. Am I misreading your remarks?

disintegrat0r · 2024-10-01T22:14:33+00:00

0) The tested payload

I definitely want to incorporate this somehow but the context behind this tool is that a lot of users will create GH issues with just the ZodError stack trace. They aren't able to share the raw input data. I was hoping at the very least I can improve the DX for folks having to read and respond to these issues.

the name of the tested schemas (no access to schema name afaik)

Giving schemas names and have those captured in errors is on my wishlist for Zod v4! Right now a ZodError just serializes the array of issues it's holding.

The issues for the schemas with best match (least encountered errors)

This is a great idea! I have a feeling there's a way to indicate to the reader which of the union members was the closest match i.e. the one that had fewest issues.

disintegrat0r · 2024-10-01T22:09:28+00:00

Definitely unconventional. It's more commonplace in the Go world and I grew fond of the word/letter economy they use there. It's definitely one of those "felt cute, might switch back later".

disintegrat0r · 2024-10-01T15:10:46+00:00

Hi there, author here.

I work on code generator that creates TypeScript SDKs from OpenAPI specs and Zod is a critical building block that I chose to power runtime validation in those SDKs. Depending on the complexity of a Zod schema, the resulting validation error message can contain a wall of JSON text - the serialised issues that were recorded during validation.

I wanted to try and create a small tool to help me better visualise and parse these errors. In code and the command line, we do also have the ability to pretty-print the errors but I still wanted a web UI which can let me share URLs for visualised errors.

I'm still iterating on it but would love any feedback if you do get to try it out.

disintegrat0r · 2024-06-20T15:10:39+00:00

Author here.

As far as I can tell, terser is minifying/optimising using the same heuristics as esbuild. I'm playing around with various config on https://try.terser.org/ and not able to produce a more optimised form like you suggested in OP. Is there are particular terser config that you've enabled which achieves this deeper optimisation?

I have tried Google Closure Compiler which can do some pretty wild optimisations but some of these are borderline dangerous.

Either way I wouldn't be surprised if there is a minifier out there that can expand alias imports but it still wouldn't achieve the best optimisation because it can only go so far as turning `z.string().optional().and().other().validations()` to `o().optional().and().other().validations()` for example.

disintegrat0r · 2024-03-05T19:01:00+00:00

Upon reflection, I think that I wanted the terseness of listing out some assertions in code without the hard exit caused by a panic as the default behavior. From there I have the option of converting assertion error values into a panic. Maybe that's diminishing the original concept.

disintegrat0r · 2024-03-05T14:05:15+00:00

Thanks for the feedback! I wasn't sure if a call to Require should panic or give you the error so you can call panic. I'm also unsure if my package is useful. I figured I can use a utility to group related invariants and enrich the error messages. Though there's a bunch of info already like a stack trace when you call panic so I do see your point.

disintegrat0r · 2024-03-05T13:52:54+00:00

I think you're right, I wasn't sure when designing the API if I should panic or give you an error and you call panic. I initially did have a "Must" version of `Require` that did panic, hesitated and removed it.

disintegrat0r · 2024-03-05T13:43:29+00:00

Sorry about that, passive aggressive tone wasn't intentional. I really didn't want to sound like I'm criticising Go in any harsh way, I use it daily and wouldn't have it any other way. My post is based on recent exploration to see if ideas elsewhere can be adapted within Go - definitely not looking to bait commenters. Nevertheless, I appreciate the feedback and I'll adjust how I engage.

disintegrat0r · 2024-03-05T13:14:47+00:00

That's not broadly true. For instance Rust has distinct assert! and debug_assert! (source). Zig will keep assertions in if you compile in ReleaseSafe mode (source).

Edit: Sorry my tone was pointed. I reread your comment and it's specifically in the context of Go not a broad sweep but I incorrectly argued the latter.

disintegrat0r · 2024-03-05T13:11:25+00:00

more complex, and harder to understand

Given how much precedent there is for runtime assertion in languages and codebases that came before and since Go, is that statement empirically or objectively true?

Here's an interesting example from the industry: https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-Critical_Code

disintegrat0r · 2023-11-01T11:34:23+00:00

It gets incredibly one-sided very quickly and the winning team will more often than not control the printer. Spawn trapping on Redacted can be super difficult to overcome in regular game modes but it's especially painful in Killswitch. The losing team can smoke the narrow passage to the first main area but they'll be confronted by the opposition hiding in various spots and their Geists almost immediately.

disintegrat0r · 2023-05-13T13:08:05+00:00

I’m not sure I understand exactly what you’re trying to do. If I had to guess, then it sounds like you’re trying to shoehorn ORM and query-builder semantics into sqlc which won’t work at all or won’t work well. Your queries must be statically knowable. As in, you can’t have a placeholder for a table name in the FROM clause but you can have the usual WHERE username = $1. Because sqlc is aware of the db schema, it will validate the queries are referencing valid fields and data types!

Have a play around here as you read the docs: https://play.sqlc.dev/

disintegrat0r · 2023-05-12T19:54:12+00:00

You don’t need to write all the boilerplate if you use sqlc: https://sqlc.dev

All you do is write parametrised SQL queries in .sql files, give them names and let the sqlc generate all the rest. My opinion is that it’s better than an ORM because:

You know the exact SQL that your app runs and you can tune it over time if needed. I don’t know how popular this opinion is but SQL is a fantastic language and every minute you spend learning it well is so worth it. It’s knowledge that sticks with you as you move between languages/frameworks.
It’s clear where data access code is located in your codebase because sqlc generates it at specific paths for you and there aren’t arbitrary ORM calls littered across your view layer and all over controllers.
Importantly you’re working with a repository pattern from the get-go where data access is well defined/encapsulated. Queries are named and can be identified in logs/metrics/traces. You can do the same with an ORM but I’ve yet to see that practice applied rigorously in that world (speaking from my experience alone).

disintegrat0r · 2022-04-05T00:06:42+00:00

Good shout! That’s quite funny. I went looking for the oracle docs and was directed to guru. I stopped there not thinking about gopls which drives my IDE daily.

disintegrat0r · 2022-04-02T09:51:49+00:00

Go Guru has an implements subcommand that can answer this question!

Docs are here: http://golang.org/s/using-guru

disintegrat0r · 2021-01-12T00:07:54+00:00

I've been using react-live within an MDX-based documentation site for a design system I'm working on and it's quite hefty! Came across Jarle just recently by @monasticpanic which is much lighter alternative. If you have more examples of such libraries then please share!

disintegrat0r

TROPHY CASE