Skip to main content
Glama

serve_locally

Start a local mock server that serves one or more APIs from OpenAPI spec files or URLs. Combines multiple APIs into a single server for local testing.

Instructions

Start ONE mockzilla portable mock server on this machine that serves any number of APIs together — no mockzilla account needed. Pass input as a single spec path / directory / public https URL, OR an array of them to combine multiple APIs into the same server (each becomes a service mounted at //...). Returns {url, port, pid, services} once listening. Pair with stop_locally(pid) to clean up. Prefer this over deploy_mock_from_* whenever the user says 'try locally', 'experiment', or 'play with' — those tools create persistent hosted bundles, this one is ephemeral. The bridge only runs ONE local server at a time on purpose: if the user wants more APIs, stop the current server and restart with all of them in input.

If the user names a well-known API (stripe, twilio, github, openai, slack, etc.) WITHOUT providing a URL, recall the public OpenAPI spec URL from your training knowledge and pass that. Do NOT pass a catalog ID or slug from list_catalog_products — that catalog is for the HOSTED deploy_mock_from_catalog flow, its ids are not URLs. Examples of public OpenAPI URLs: • Stripe: https://raw.githubusercontent.com/stripe/openapi/master/openapi/spec3.json • Twilio: https://raw.githubusercontent.com/twilio/twilio-oai/main/spec/json/twilio_api_v2010.json • GitHub: https://raw.githubusercontent.com/github/rest-api-description/main/descriptions/api.github.com/api.github.com.json • Petstore: https://petstore3.swagger.io/api/v3/openapi.json

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputYesSpec file path(s), directory, or public OpenAPI URL(s). Pass an array to combine multiple APIs into one server.
portNoPort to bind on. Omit or pass 0 to let the OS pick a free port.
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description covers key behaviors: starts a server, returns {url, port, pid, services}, is ephemeral, runs only one server at a time, and requires pairing with stop_locally. Lacks mention of permissions or resource cleanup, but overall transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is informative but somewhat lengthy, containing multiple paragraphs and examples. It is well-structured with a clear first sentence, then details and usage guidance, but could be more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (local server, multiple APIs, output details) and lack of output schema, the description fully explains the behavior, output format, cleanup, and edge cases like well-known APIs. No gaps identified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but description adds significant value: explains that input can be a single path/directory/URL or an array, each becoming a service mounted at /<service>/. Provides examples of well-known API URLs and cautions against using catalog IDs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool starts a mockzilla portable mock server locally, specifying it can serve multiple APIs from spec paths or URLs. It distinguishes itself from sibling deploy_mock_from_* tools by emphasizing ephemeral local usage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to prefer this over deploy_mock_from_* when user says 'try locally', 'experiment', or 'play with'. Provides guidance on stopping current server and restarting with all APIs. Also explains how to handle well-known APIs without a URL by recalling public OpenAPI specs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mockzilla/mockzilla-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server