Agent Studio on Desktop: Let 80+ AI Models Call Your Local MCP Tools
Nikhil Tiwari
MCP Playground
π TL;DR
- Agent Studio is a chat where an AI model calls your MCP tools. In the desktop app, those tools can be local stdio servers that no website can reach.
- The agent loop runs on your computer. Only the model request goes through MCP Playground. Server commands, env vars and tokens stay local.
- Pick from 80+ models (Claude, GPT, Gemini, Grok, DeepSeek, Qwen and more) and switch mid-chat to compare them on the same tools.
- Approvals depend on your tool annotations. The default asks only before tools marked
destructiveHint: true. Choose Writes for servers you're still building. - Each message costs the model's credit price once, however many tool calls it makes. The price is shown next to each model.
Table of Contents
- Why test with a model, not just by hand
- Your first chat in four steps
- Tool approvals and annotations
- What leaves your computer
- Models and credits
- Several servers in one chat
- Four tests worth running
- Chat history and sync
- FAQ
Why test with a model, not just by hand
Calling a tool yourself in the Tester proves it runs. It doesn't tell you whether a model will pick it, or fill in its arguments correctly. That depends on the tool name, the description and the input schema, and models read them differently.
Agent Studio closes that gap. You ask in plain English, and you watch which tool the model calls, with what arguments, and what it does with the result. Every call is shown in the chat.
The web version of Agent Studio can only reach servers on a public URL. MCP Playground Desktop runs the same agent inside the app, so it can use servers that start as a local command: the one you're building, a filesystem server, a database on localhost.
Your first chat in four steps
- Add an MCP server in the sidebar. Choose one from Popular, Import your servers from Claude Desktop, Cursor or VS Code, or add your own stdio command or URL. Not sure how? See importing your config or adding a Python server.
- Tick it under Servers in the Agent Studio sidebar. Only ticked servers' tools are given to the model.
- Pick a model. The picker shows each model's credit price and has filters for β€ 4 credits and Reasoning.
- Ask. The empty chat suggests three good first prompts:
- "What tools do you have, and what does each one do?"
- "Call each read-only tool once and summarize what you get back."
- "Review my tool schemas and descriptions for anything an agent would misuse."
Shortcut from the Tester: once a server's tools have loaded, a Try in Agent Studio button appears above the tool list. It opens a new chat with only that server ticked.
If a ticked server fails to connect, the others still work and the model is told which one is missing. If none connect, you get "None of the selected servers connected. Open them in the Tester tab to see why." The Tester shows the full error and the server's stderr.
Tool approvals and annotations
Open Advanced settings in the Agent Studio sidebar. Ask before running tools has three options:
| Option | Asks before | Use it for |
|---|---|---|
| Destructive (default) | Tools the server marks destructiveHint: true | Well-annotated servers you trust |
| Writes | Every tool not marked readOnlyHint: true | Servers you're building, and servers you don't control |
| Never | Nothing | Throwaway data only |
When a call needs approval, the chat shows the tool, the server and the exact input as JSON, with three buttons: Run once, Always allow in this chat and Don't run. If you decline, the model is told not to retry and to ask you how to continue.
A tool with no annotations runs without asking under the default. The Destructive option only asks when the server explicitly sets destructiveHint: true. Many servers in development don't set annotations at all, so switch to Writes while you build. It's also a good reason to annotate your tools.
Annotations are part of each tool in tools/list. A read-only tool and a destructive one look like this:
{ "name": "search_notes", "annotations": { "readOnlyHint": true } }
{ "name": "delete_note", "annotations": { "readOnlyHint": false, "destructiveHint": true } }
Annotations are hints from the server, not guarantees. The app's own setting reminds you that tool results can contain instructions aimed at the agent, so keep approvals on for servers you don't control. MCP server vulnerabilities in 2026 covers why.
What leaves your computer
Before your first chat, the app shows a notice listing exactly this. Sent to the model provider, through MCP Playground:
- Your messages and system prompt
- Tool names, descriptions and input schemas
- The inputs the agent passes to tools and everything the tools return, including file contents or secrets a tool prints
Stays on your computer:
- Server commands, URLs, env vars, headers and tokens
- Everything you do in the Tester tab
- Your chat history, saved encrypted on this computer
MCP Playground keeps usage records (model, credits, device and time), not your messages or tool results, unless you sync a chat. The practical rule: don't connect a server whose output you couldn't share with a model provider. Tool results are sent to the model, so if a tool prints an API key, the model sees it.
Models and credits
The model list has 80+ models from Anthropic, OpenAI, Google, xAI, DeepSeek, Qwen, Mistral, Meta, Moonshot, MiniMax, NVIDIA and Z.ai. Models that can reason show a small brain icon.
A message costs the model's credit price once. The agent can call several tools and take several steps for that message, and it's still one charge. Prices run from 1 credit for small open models to more for the largest ones, and the picker shows each price. Your balance is in the Account card in the sidebar, with a Buy credits link. The header shows how many credits the current chat has used.
Each message has a step limit, so a confused model can't loop forever. Tool results longer than 60,000 characters are cut off before they go back to the model, with a note saying how long the full result was. If you see that note, add a limit or pagination parameter to the tool.
For cheap first tests, start with a 1β2 credit model. Move to a larger one when you want to see how a strong model uses the tools, or when a small one fails and you want to know whether the tool or the model is at fault.
Several servers in one chat
Tick more than one server and the agent gets all of their tools. With one server, tool names stay as they are. With several, each name gets the server's name in front, such as github__create_issue and filesystem__read_file, so two servers can both have a search tool.
This is where local and remote servers meet: a local filesystem or SQLite server next to a hosted GitHub or Linear server, in one chat. The MCP agent use cases post has ideas for combinations.
Four tests worth running
1. Does the model pick the right tool?
Ask for the task in the user's words, not the tool's: "how many words are in this paragraph?" rather than "call word_count". If the model picks the wrong tool, or answers without any tool, the description is the first thing to fix.
2. Does it fill in the arguments correctly?
Open each tool call in the chat and read its input. Look for dates in the wrong format, IDs the model invented, and optional parameters it always leaves out. Each of these points to a schema or description that needs an example or an enum.
3. Does it handle errors?
Ask for something that will fail: a file that doesn't exist, an ID that's wrong. A good error result (isError: true with a clear message) lets the model explain or try again. A thrown exception or an empty result usually doesn't.
4. Do different models agree?
Ask the same question, switch models in the picker, and ask again in the same chat. Each reply shows which model wrote it. A tool that only works with one model family usually has a description that relies on that model's guesses.
When these work in chat, turn them into repeatable checks. How to test your MCP tool descriptions covers what to fix.
Chat history and sync
Chats are saved automatically, encrypted, on your computer. Open them with the History button in the Agent Studio header. Reopening a chat restores its model and servers.
Each chat can be synced on its own. Sync to my account stores that chat, tool results included, in your MCP Playground account, where it shows up read-only in the web Agent Studio history. Server commands, env vars, headers and tokens are never uploaded, only server names and hosts. Turn sync off and the account copy is removed.
You can also add your own instructions under Advanced settings β System prompt. They're added to the default prompt, which tells the agent which tools it has and how to report failed calls. A line like "You are a support agent for Acme" is a quick way to test your tools in the setting they'll really be used in.
FAQ
How do I test a local MCP server with an AI model?+
Are my server commands and API keys sent anywhere?+
How much does an Agent Studio message cost?+
Why did a tool run without asking me?+
Can I use several MCP servers in one Agent Studio chat?+
Conclusion
Testing a tool by hand tells you it works. Agent Studio tells you whether a model can use it: whether it picks the tool, fills in the arguments and handles the errors. On the desktop app that works for the local server you're building, before you deploy it anywhere.
Written by Nikhil Tiwari
15+ years in product development. AI enthusiast building developer tools that make complex technologies accessible to everyone.
Free MCP Tools (no install)
Build, compare & ship MCP agents
Connect any MCP server, run evals on it, compare 90+ models side-by-side, deploy hosted servers, and save reusable agents you can export as an API β all in your browser.