foro
Docs navigation

Use cases

What actually fits on foro.sh

foro.sh deploys one MCP server per project - Python built with uv, Poetry, pipenv, PDM, or a plain requirements.txt, or Node built with npm, pnpm or yarn, served over streamable HTTP, hosted in the EU - to a stable URL it generates for you. That shape suits some kinds of servers a lot better than others. Here are the five that fit cleanly, and a dedicated guide for each.

Fit isn't about how big or small the project is. A one-tool weekend script and a company-wide internal connector can both be a clean fit, or both be the wrong shape, depending on three questions: does it need to write and remember state between calls, does more than one person need to authenticate as themselves rather than share a token, and does it talk to one system or several. The five guides below answer those questions for the shapes people build most often.

One upstream API, wrapped in a few tools

A handful of tools, each making one call to a single upstream API and handing back the answer. No writes, no memory between calls.

shape: Read-only API wrapperbest for: solo devs, small teamsstate: noneauth: single token

When the agent needs to remember something

A scratchpad, a running log, a todo list - anything where one call has to remember what an earlier call wrote down.

shape: Stateful toolbest for: individuals, small teamsstate: in-memoryauth: single token

Point an agent at data that has to stay inside the company

A narrow, purpose-built proxy in front of an internal database or API - the server itself holds no data.

shape: Internal data connectorbest for: platform & tooling teamsstate: external, proxiedauth: OAuth 2.1 + SSO

Hands for an agent, not just an opinion

Small, specific actions - convert this file, resize that image, post a notification - rather than answers.

shape: Personal automationbest for: individual developersstate: none or short-livedauth: single token

Wrapping your own tooling so an agent can use it too

Did main just break, what shipped since yesterday - a narrow proxy in front of CI, the deploy pipeline, an error dashboard.

shape: Dev-tool serverbest for: engineering teamsstate: external, proxiedauth: OAuth 2.1 + SSO

The same questions decide fit for all five shapes: whether the server holds state, who's calling it, and how many systems sit behind the tools - project size isn't one of them. If a project doesn't map cleanly onto one of these, the likely reason is that it needs many outside customers to authenticate as themselves against one shared server, which is a different hosting shape than foro runs today. Everything above it is a matter of pointing foro at the repo and letting it read the project for itself.