MCP vs API: which to choose
MCP rides a subscription you already hold. A provider key buys a specific model and tighter spend. The numbers, and what only the built-in chat can do.
Guide
Run a local LLM in your Foundry VTT game.
Familiar's chat can talk to a model running on your own PC instead of a cloud provider. Point the Local / Custom tab at Ollama, LM Studio or llama.cpp, flip one switch, and your table runs on a model you host yourself. Your world never leaves that machine, and no provider bills you per token. The trade is speed. Without a discrete GPU, a reply takes minutes rather than seconds.
The runner, the network, and the bill
A runner is an app that serves a model on your machine. You install one, load a model into it, and Familiar sends your messages there instead of to a hosted provider. Your prompts, the world context that travels with them, and every reply all stay on your own hardware.
A few requests still reach the network when a world loads, and not one of them carries your game. Familiar refreshes the model list so the dropdowns stay current, and it checks your licence with Polar. That call sends the key and Familiar's Polar organisation id, nothing else. The licence answer is cached for a week, so an offline evening plays straight through.
No provider key, and no per-token bill. That is not the same as free. You pay in the graphics card you already own and the power it draws while it thinks, and if you own the wrong hardware you pay in waiting.
Local setups vary far more than hosted ones, so this is where the rough edges surface first.
What it asks of your setup
Two things decide whether local play feels good: the model you load and the hardware under it. Check both before you download several gigabytes of weights.
The model has to call tools. Familiar works by calling them: rolling the dice, applying a condition, opening the right journal page. Hand the job to a model that cannot, and it narrates an attack that never happened, which is worse than a refusal because it looks like it worked. Small models lose that skill first, so the floor is a tool-trained model of 14B or more, at Q4_K_M quantisation or better.
That floor buys you tool calls, not fights. Switching combat on roughly triples the tool definitions the model has to hold, and turns a single turn into a chain of calls. Combat gets comfortable at 27B to 32B dense, or on a 30B to 35B mixture-of-experts model, which wants about 24 GB of video memory.
Hardware sets the speed. The request Familiar sends carries the core tool definitions plus your world context, about 15,000 tokens before you have typed a word in a small test world. A 24 GB card works through that in seconds. On a CPU-only machine a turn took 5 to 10 minutes in July, on a smaller request than today's. A whole exchange is capped at fifteen minutes, so a multi-step turn does not fit on CPU at all.
- A model your runner marks as able to call tools, at the floor or above. A non-thinking variant is the right pick when speed matters.
- A context window of 32K, so a conversation still fits after the first request. On an 8 GB card that pushes part of the model onto the CPU, and every turn slows down.
- A way of reaching Foundry that lets the call through. The desktop app or a localhost tab always does; the rest is under Where your browser allows this.
Familiar waits up to five minutes for the first token from a local server, where a hosted provider gets two. That is headroom for slow hardware. A turn that needs it will feel slow at the table.
| Video memory | Model | What to expect |
|---|---|---|
| 8 GB | qwen3:8b | Under the floor. A single tool call, such as a dice roll, lands; a fight is marginal. |
| 12 GB | qwen3.5:9b or gemma4:12b | More headroom, still under the floor. |
| 16 GB | gpt-oss:20b | Over the floor, short of comfortable in a fight. |
| 24 GB | qwen3.6:27b, or qwen3.6:35b (mixture of experts) | Where combat gets comfortable. |
| Apple silicon, 32 GB or more | qwen3.6:27b | Unified memory does the work of video memory. |
Checked on 3 November 2026: every name exists in Ollama's library, and I ran the 8 GB row on an RTX 2070: the d20 below. Line-ups change monthly. When a name here has gone, the criteria above still pick its successor.
Pick a runner
Familiar ships a preset for four runners. Keep the runner and the model apart while you set this up: the runner is the plumbing, the model you load into it is the brain.
| Runner | Base URL | What you set |
|---|---|---|
| Ollama | http://localhost:11434/v1 | The context window, before your first message |
| LM Studio | http://localhost:1234/v1 | Context Length when you load the model, then Enable CORS |
| llama.cpp | http://localhost:8080/v1 | Nothing on current builds. Older ones need the jinja chat template for tool calls |
| LiteLLM | http://localhost:4000/v1 | The master key, and which origins the gateway accepts |
Ollama is the shortest path of the four. LiteLLM is the one to reach for when several backends sit behind one address, or when the runner itself should not face the browser. Point LiteLLM at a hosted model and you are back to a provider key and a token bill, and your world goes to that provider: the gateway is local, the model is not.
Ollama: raise the context window first
Ollama on the same machine is close to zero configuration. Its defaults already accept a Foundry page served from localhost, so there is nothing to allow and no key to set.
One setting decides whether it works. Ollama ignores the context size a client asks for, loads at 4K, and truncates in silence. No error appears. The model forgets the tool definitions and half the conversation, and starts describing actions instead of taking them.
Set it in the environment that starts Ollama, restart Ollama, and check the result with ollama ps. The CONTEXT column reports what the loaded model got, which is the only number worth trusting here.
OLLAMA_CONTEXT_LENGTH=32768
ollama ps
LM Studio: the CORS switch is off by default
LM Studio serves the model from its Developer view, which its default mode hides. Five steps take it from install to serving.
Turn Developer Mode on
The first-run setup offers it as a toggle. Clicked past that screen? The gear icon at the bottom left, then Settings, then Developer.
Load the model with room to work
Drag Context Length to 32,768 before you press Load. LM Studio wants it set as you load, not after, and its default of 4,096 or 8,192 fills up before your first message is read.
Look for the hammer
The tool-use badge, a small hammer, sits beside a model that can call tools. No hammer means it cannot call Familiar's tools, however well it writes.
Start the server
Open the Developer view with the </> icon or Ctrl+2, start the server, and note the address it reports, normally http://localhost:1234.
Switch Enable CORS on
Without it the browser blocks the request before it leaves the page, and Familiar reports that it could not connect to the AI provider while nothing ever reached LM Studio. LM Studio warns that any website you visit can then call your server, and it is right: stop the server when you are not playing.
Point Familiar at your server
Everything for this path lives on one settings tab. In Foundry, open Module Settings, then Familiar, then Configure AI, and pick Local / Custom under Connections, just below MCP / Subs.
Four fields, one switch, one test. You do this once.
Pick your runner
The Preset dropdown lists Ollama, LM Studio, llama.cpp and LiteLLM, then Venice, the one hosted entry (the aside further down says what that changes), and Other for anything else that speaks the OpenAI chat API.
Check the Base URL
The preset fills it in up to /v1, and Familiar appends the rest itself. If your runner reported a different port when it started, correct it here.
Leave the API key empty
A local runner normally wants no key at all. A gateway does: paste the key it expects, such as your LiteLLM master key.
Type the model id
Type the exact id your server serves. Once the server answers, the field suggests what it found, but it is required either way.
Flip Use for chat on
This is the switch that moves the built-in chat over to your server, and it is the only route there: the provider list on the Chat tab does not offer your server, and neither does asking your AI to change provider. The hosted provider on the Chat tab stays saved, so going back later is one flip.
Hit Test connection
It sends a small real message to your server, so a connected result means the whole path works and not merely that the port is open.
Ask it for a d20
Open the chat and ask it to roll a d20. If the roll lands in Foundry's chat log, your model is calling tools and you are done.
If the reply only describes a roll, or says it has no way to roll one, nothing ran in Foundry: see the row "It describes an action" under When it does not work.
Where your browser allows this
The chat calls your server straight from the Foundry page. That keeps this path simple, with no bridge and nothing in the middle. It also hands the decision to your browser: what it allows depends on how you reach Foundry.
Familiar supports the field, not your backend. The Local / Custom tab and the connection it makes are ours to fix; the server, the model, and the machine under them are yours. If a model misbehaves through your runner but behaves elsewhere, start there.
| How you run Foundry | Does it work? |
|---|---|
| The desktop app, or a browser tab on localhost, with the runner on the same machine | Yes. Nothing to configure and no prompt. |
| Hosted Foundry over https, The Forge for example, with the runner on your own PC | Yes, after one prompt. Chrome asks once for access to your local network, and granting it sticks. Your runner also has to accept your game's address, which on Ollama is the OLLAMA_ORIGINS setting. |
| Hosted Foundry over https, with the runner on a second PC reached by its LAN address | No. An https page cannot make a plain http call to a LAN address, so the browser blocks it as mixed content. Give that server https, front it with a gateway, or move it to the machine you play on. |
| Any Foundry served over https, opened in Safari | No. Safari blocks an https page from reaching a local server, whether that is a hosted game or your own Foundry with its HTTPS switched on. Use Chrome, Edge, or Firefox, or play in the desktop app. |
Open your own game by its LAN address instead of localhost and it becomes a new origin to your runner, which needs the same allowance as the hosted row above.
When it does not work
Work down the table before you change the model.
| What you see | What it means | What to change |
|---|---|---|
| Failed to connect to AI provider, the instant you send | The request never left the browser | CORS is off in LM Studio, the server is not running, or the port in the Base URL is wrong. |
| Enter a model id first, when you test the connection | The Model field is empty | Type the id your server shows for the loaded model. The suggestions are a convenience; the field is required. |
| Familiar rejects your Base URL | The address breaks the URL rules | Familiar accepts https anywhere, and plain http only for localhost or a private LAN address; the browser rules above still decide whether the call goes through. |
| An error about the available context size as soon as you send | The window is too small for the tool definitions | Reload the model at the size under What it asks of your setup. On Ollama, set it in the environment and restart. |
| It describes an action or says it has no tool for it, and nothing happens in Foundry | It is not calling tools | Check the model is tool-trained and big enough. On Ollama, run ollama ps: a model loaded at 4K drops its tools without an error. Then update your runner. If calls arrive but look garbled, turn Streaming off on the Local / Custom tab to isolate it. |
| The first reply takes minutes, or Familiar reports the endpoint too slow | Hardware, not setup | No setting fixes this one. A discrete GPU, a smaller model, or a hosted provider for the nights that lean on tools. |
Expect one more thing rather than fixing it: a model that streams its reasoning has that rendered in the collapsible Thinking view instead of the reply, and the thinking still costs real time on slow hardware.
A speech server on the same machine
The Voice tab has the same idea for speech. Pick Custom TTS (OpenAI-compatible) as a voice provider and point it at any server that answers OpenAI's speech call, with the key left empty when the server wants none.
An address on your own machine or your home network is fine, 127.0.0.1 or a 192.168 one. Familiar stops a provider from redirecting it to an internal address, with one exception: the address you typed into this row. The browser rules above apply unchanged, since the speech call is browser-direct as well.
Open weights without the graphics card
Plenty of people reach for local because they want open weights, and local is only one way to get them. The same open models run on hosted services at full precision, over https, on someone else's GPU. Groq, Cerebras, DeepSeek, and OpenRouter already sit in the Chat tab's provider list, and none of them needs CORS, a graphics card, or a context setting.
The Local / Custom tab carries one hosted entry of its own, Venice. That route leaves your network and bills your Venice account, so the privacy and no-bill lines at the top of this page stop applying. Thinking there follows Venice's own model list, which says which models take a level.
Local earns its place on the other axis: your world stays on your machine. Pick it for that.
Try it on one scene
Load a model, point the Local / Custom tab at it, and run one short scene: a conversation, a skill check, a single fight. That is enough to tell you whether your machine is up for a whole session.
If it drags, you have spent a download and learned something concrete about your hardware. If it flies, the whole table is yours. Either way, tell me how it went in the Discord.
More in Choices around the connection
Choosing an AI model
Which model holds a tool chain together, where to get one, and when to turn the thinking up or down.
New to Familiar? I'm Ryan, the person who built it. The Discord is small and brand new, so if you join now I'll help you get set up myself.