Mockbird

create_project

Create a new mock REST API project. Returns {id, adminKey, baseUrl, resources[]}. SAVE the adminKey — it is required for admin operations (add_resource, custom_route, snapshots) and is shown only once. Presets seed a full backend: blog (posts/comments/authors), ecommerce (products/orders/customers/reviews), saas (users/teams/events), openai (ready OpenAI-compatible mock — chat completions incl. streaming SSE, embeddings with a real 1536-dim vector, models; point OPENAI_BASE_URL at {baseUrl}/v1). Omit preset for a starter project (one seeded "items" resource — live data immediately, reshape or delete it); use "blank" for a truly empty project you fill via add_resource or import_data. The mock API is then live at baseUrl: standard REST CRUD (GET/POST/PUT/PATCH/DELETE), CORS enabled, no auth needed.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	No	Project name (max 60 chars). Optional.
`preset`	No	Seeded preset; 'blank' = truly empty. Omit for a starter project. Optional.

TDQS

A4.7/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It thoroughly discloses side effects: adminKey shown only once (must be saved), mock API is live at baseUrl with standard REST CRUD, CORS enabled, no auth. However, it doesn't explicitly state this is a creation/mutation operation or discuss reversibility/deletion behavior.

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

Conciseness5/5

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

The description is well-organized and front-loaded with the core purpose (create project + return payload). Every sentence earns its place: adminKey warning, preset explanations, live API details. No wasted words despite the richness of content.

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?

Comprehensive for a 2-param creation tool with no output schema. It covers return format, authentication implications (adminKey), presets with concrete details, live API behavior (CRUD, CORS, no auth), and how this tool fits with siblings (add_resource, custom_route, snapshots). No significant gaps remain for an agent to invoke correctly.

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

Parameters4/5

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

Schema coverage is 100%, so parameters are well-documented in the schema. The description adds substantial value beyond the schema: explaining exactly what each preset seeds (blog, ecommerce, saas, openai specifics including SSE streaming and 1536-dim vectors), what 'omit preset' means (starter project with items resource), and what 'blank' produces. This exceeds the baseline 3 for high coverage.

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 'Create a new mock REST API project' and specifies the return payload {id, adminKey, baseUrl, resources[]}. It distinguishes itself effectively from siblings (add_resource, import_data, etc.) by explaining that this is the project initialization tool while others manipulate an existing project.

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?

Excellent guidance. It explicitly explains when to use each preset (blog, ecommerce, saas, openai) and when to omit preset for a starter project vs 'blank' for a truly empty one. It clarifies the admin operations that require adminKey (add_resource, custom_route, snapshots), giving the agent concrete decision criteria.

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

All Mockbird tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Each tool maps to a distinct resource/operation: project lifecycle, resource seeding, artifact import, record CRUD, custom routes, snapshots, request inspection, and external API status. Even the data-population tools are clearly separated by existing project (add_resource) versus new project (import_data/create_project).

Naming Consistency4/5

Most tools follow a clear verb_noun pattern (add_resource, create_project, query_records, write_record, delete_project, etc.). A few noun-style names (custom_route, project_info, snapshots) break the pattern, but all names are snake_case and readable.

Tool Count5/5

Eleven tools is a well-scoped set for a mock API server: project creation/deletion, data population/import, record operations, snapshots, custom routes, inspection, and API status all have dedicated tools without redundancy.

Completeness4/5

The core workflow is well covered: create/delete projects, add/import resources, CRUD records, snapshot state, define routes, and inspect requests. The main gaps are the lack of explicit resource deletion and custom-route update/delete, but these are workaroundable rather than blocking.

Resources

Need Help?