> I still haven't figured out MCP or how/why to use them or why to bother. You run servers. I guess. It's too complex for my smol brain to understand
I know this is self-deprecating humor, but you do NOT have a smol brain: MCP servers are not as needed anymore now that Claude Code supports "Skills". They are also very token hungry as their spec is not lazy-loaded like the skills.
It was / and still is very useful if you collaborate with other engineers or want to perform operations in a non-stochastic fashion.
MCP servers are a way to expose a set of APIs (openAPI spec) to an LLM to perform the listed operations in a deterministic fashion (including adding some auditing, logging, etc). LLMs are fine-tuned for tool calling, so they do it really well and consistently.
Examples:
- Documentation / Glossary: MCP server that runs somewhere that reads a specific MD file or database that is periodically updated: think "what are my team members working on" / "let me look up what this means in our internal wiki".
- Gating operations behind authentication: a MCP server that is connected to your back office and allows you to upgrade a customer's plan, list existing customers, surface current. Super useful if you're a solo-founder for example.
Additionally, keep in mind that controversial laws or proposals, at least in France, are often announced or passed during summer vacation when people are away, limiting scrutiny and attention.
If you have heard of pg-boss
[1], how does sidequest compare to it? I’m about to embark on some « jobification » on some flows and I’d love to have your opinion (possibly biased, but still)!
Thanks for the question! I just checked out pg-boss. Solid library if you're fully on Postgres. Sidequest.js takes a broader and more flexible approach. Key differences:
Database agnostic: Sidequest isn't tied to Postgres. It also works with MySQL, MongoDB, and SQLite, which helps if your stack isn’t Postgres-based.
Job isolation: Jobs run in worker threads, so heavy tasks won’t block your main Node.js process. Express APIs stay responsive.
Distributed coordination: Designed to run across multiple instances. One node picks up the job, and if it fails, another can retry. This is built-in.
Built-in dashboard: Includes a web UI to inspect, retry, or cancel jobs.
More than queues: Supports cron jobs, uniqueness constraints, per-queue concurrency, and configuration. Some of this overlaps with pg-boss, but the intent behind Sidequest is to provide a complete solution for job processing.
If you just need simple queues in a Postgres-only setup, pg-boss is great. If you want more flexibility, tooling, and backend options, Sidequest may be a better fit.
Wow, that really means a lot coming from you! I’ve come across SimplePDF quite a few times while researching! Super impressed by what you’ve built. Thanks for the kind words, fellow PDF’er
> Further, one of the issues with remote servers is tenancy
Excellent write-up and understanding of the current state of MCP
I’ve been waiting for someone to point it out. This is in my opinion the biggest limitation of the current spec.
What is needed is a tool invocation context that is provided at tool invocation time.
Such tool invocation context allows passing information that would allow authorizing, authentication but also tracing the original “requester”: think of it as “tool invoked on behalf of user identity”
This of course implies an upstream authnz that feeds these details and more.
If you’re interested in this topic, my email is in my bio: I’m of the architect of our multi-tenant tool calling implementation that we’ve been running in production for the past year with enterprise customers where authnz and auditability are key requirements.
The way we've solved this in our MCP gateway (OSS) is that the user first needs to authenticate against our gateway, e.g. by creating a valid JWT with their identity provider, which will be validated using JWKS. Now when they use a tool, they must send their JWT, so the LLM always acts in their behalf. This supports multiple tenants out of the box. (https://wundergraph.com/mcp-gateway)
I mean, converting a tool-less LLM into a tool-using LLM is a few hundred lines of code, and then you can plug all your tools, with whichever context you want.
My point is about the need for a spec of this mechanism: without a spec, every company / org will roll out their own and result in 500 flavors of the same concept.
That’s where MCP shines: tool calling and tool discovery is already 1.5 years old (an eternity in ai land).
The MCP spec ensures that we can all focus on solving problems with tool calling rather than wasting time in cobbling together services that re not interoperable (because developed without a common spec / standard)
We're building an enterprise platform to develop, deploy, and run AI agents at scale — from local dev to production. Founded by ex-Hortonworks, Docker, and Cloudera folks, Sema4.ai is a well-funded startup with deep infra and OSS roots.
We're looking for a fullstack engineer to join our platform team. You'll help shape the core infrastructure that powers agent-based workflows for enterprises.
Technologies we use include:
- K8s, Helm, OTel
- Node.js, React
- AWS
- Snowflake SPCS
What we're looking for:
- Strong builder mindset — pragmatic, self-driven
- Comfortable in startup environments
- Clear communicator in distributed teams
- Bonus: experience with observability / infra / developer platforms
If you're interested, reach out to ben@sema4.ai with a short intro and (ideally) your GitHub or past projects.
I don’t want to sit in a taxi that’s remote controlled by someone who has low stakes (their body not in the way of harm). There will be a number of accidents attached to the self driving mechanism, so I can make an informed decision, but there won’t be such a number for the person taking over remotely.
Really? You're surprised that I don't want to get in a vehicle driven by Greg in Florida while he's scratching his nuts? ... Or Javinder in India while he's got a side eye on how his cricket bet is going?
Count me out. This is a laughable version of the promised vision.
You'd think that if they can't get a reliable self driving car given how much training data they must currently have, perhaps they need to try a different strategy.
Yes I learned that too a while ago. If you say anything slightly positive about Tesla, you'll be downvoted into oblivion. I can't wait for the day for this US/Western tribalism to cool down and we can have substantive discussions again.
I know this is self-deprecating humor, but you do NOT have a smol brain: MCP servers are not as needed anymore now that Claude Code supports "Skills". They are also very token hungry as their spec is not lazy-loaded like the skills.
It was / and still is very useful if you collaborate with other engineers or want to perform operations in a non-stochastic fashion.
MCP servers are a way to expose a set of APIs (openAPI spec) to an LLM to perform the listed operations in a deterministic fashion (including adding some auditing, logging, etc). LLMs are fine-tuned for tool calling, so they do it really well and consistently.
Examples:
- Documentation / Glossary: MCP server that runs somewhere that reads a specific MD file or database that is periodically updated: think "what are my team members working on" / "let me look up what this means in our internal wiki".
- Gating operations behind authentication: a MCP server that is connected to your back office and allows you to upgrade a customer's plan, list existing customers, surface current. Super useful if you're a solo-founder for example.