Bunstation

Create Cloud endpoint

projects_cloud_endpoint_create

Create one HTTP endpoint: one method, one path, and one Hono route. Do not create login, signup, or /auth routes. Auth already exists at projectUrl/auth/v1. Call this once per route. Platform CORS allows browser fetch from any domain.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_id": "<project_id>"
    },
    "name": "projects_cloud_endpoint_create"
  }
}

Input Schema

Name	Required	Description
`env`	No	String map. Do not put these values in public website source.
`name`	No	Optional DNS label, lowercase, max 32 characters.
`path`	No	HTTP path starting with /, for example /orders or /orders/:id.
`method`	No	HTTP method. GET, POST, PUT, or DELETE.
`source`	No	TypeScript source exporting a Hono app with exactly one app.get, app.post, app.put, or app.delete.
`starter`	No	Starter used when source is omitted. Login and signup are not starters. Auth is projectUrl/auth/v1.
`project_id`	Yes	UUID of a Bunstation project owned by the authenticated user.
`dependencies`	No	npm packages, for example { "hono": "^4.0.0" }.

Output Schema

Name	Required	Description	Default
`id`	Yes
`url`	Yes
`name`	Yes
`path`	Yes
`method`	Yes
`source`	Yes
`status`	Yes
`truncated`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the bar is lower. The description adds useful context — auth is provisioned at projectUrl/auth/v1 and platform CORS is open — but says nothing about conflict behavior on a duplicate method+path, whether the endpoint goes live immediately, or interaction with enable/publish/stop.

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?

Short, front-loaded, and every sentence carries a constraint or a fact. The auth point is repeated between the main text and the starter parameter description, which is mild redundancy, but nothing else is wasted.

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

Completeness3/5

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

An output schema exists, so return values need not be explained, but for a non-idempotent creation tool with 8 parameters and nested env/dependencies objects, key behaviors are still absent: duplicate-route handling, deploy timing, and any prerequisite on cloud enablement.

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

Parameters3/5

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

Schema description coverage is 100% and the enum values for method and starter are already documented, so the schema carries parameter meaning. The description reinforces the one-route constraint on source but adds no format, default, or interaction detail (e.g., source vs starter precedence) beyond what the schema already states.

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?

States a specific verb and resource ('Create one HTTP endpoint') plus the exact granularity ('one method, one path, and one Hono route'), which cleanly separates it from the sibling projects_cloud_endpoint_get and projects_cloud_endpoint_update tools. An agent knows immediately what this produces.

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?

Gives explicit when-to-call guidance ('Call this once per route') and a clear exclusion ('Do not create login, signup, or /auth routes'), which is genuine negative guidance. It stops short of naming sibling alternatives (e.g., starter templates or the update tool) or stating prerequisites like whether cloud must be enabled first.

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

All Bunstation tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?