Skip to main content
Glama

Mockbird

by dev.workers.mockbird.mockbird
OverviewDiscussionsAdmin

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), payments (Stripe-shaped sandbox: charges/refunds/subscriptions/customers + payment_intent create→confirm flow + /v1/balance — no keys), 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. Every project also serves a mock OAuth2/OIDC provider at {baseUrl}/.well-known/openid-configuration (PKCE code flow, client_credentials, RS256 JWKS — any client_id works) for testing auth flows.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ttlNoOptional: self-expiring project — auto-deletes after this many seconds (60–604800, i.e. 1 min to 7 days). Perfect for CI/eval sandboxes that must not leak even when the run crashes. Extend or cancel later via HTTP: PUT /api/projects/:id/settings {"ttl": seconds | null}.
nameNoProject name (max 60 chars). Optional.
presetNoSeeded preset; 'blank' = truly empty. Omit for a starter project. Optional.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / preset / enum
      Previous value: -[
-  "blog",
-  "ecommerce",
-  "saas",
-  "openai",
-  "blank"
-]New value: +[
+  "blog",
+  "ecommerce",
+  "saas",
+  "payments",
+  "openai",
+  "blank"
+]
  2. Changed1 schema field changed
    • addedInput schema / properties / ttl
      Added value: +{
+  "description": "Optional: self-expiring project — auto-deletes after this many seconds (60–604800, i.e. 1 min to 7 days). Perfect for CI/eval sandboxes that must not leak even when the run crashes. Extend or cancel later via HTTP: PUT /api/projects/:id/settings {\"ttl\": seconds | null}.",
+  "type": "number"
+}
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description fully carries behavioral disclosure. It reveals the return shape, warns that adminKey is shown only once, explains preset behavior in detail, and documents live API behavior, CORS, auth, and the bundled OAuth2/OIDC provider.

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 long, but almost every sentence carries actionable information about presets, return values, security, or service behavior. It is front-loaded with the core purpose and then expands into necessary operational details, making the length justified.

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 no output schema, this description is unusually complete: it specifies the returned fields, the one-time adminKey, preset semantics, TTL lifecycle, live endpoint behavior, auth expectations, and the OAuth provider. An agent has everything needed to create and immediately interact with the project.

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?

Although the schema already covers 100% of parameters, the description adds substantial meaning: it explains what each preset seeds, what 'blank' means, what a starter project contains, and how ttl expiration can be extended or canceled via HTTP. This goes well beyond the schema descriptions.

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?

Opens with a precise 'Create a new mock REST API project' statement that clearly identifies the verb, resource, and tool scope. It is immediately distinguishable from sibling tools like add_resource or fork_project.

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

Usage Guidelines4/5

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

Provides clear guidance on when to use presets, when to omit preset for a starter project, and when to use 'blank'. It does not explicitly contrast with sibling tools such as fork_project, but the context is strong enough for an agent to know this is the entry-point creation tool.

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

All Mockbird toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources