Skip to main content
Glama
Sign In

Koppar

by ai.koppar.app
OverviewDiscussionsAdmin

Create a design

create_design

Start a new design from the user's brief (what the board must do, its interfaces, power, size and constraints). Returns the design_id every other tool takes and the web_url where the user follows the design. Uses no generation quota: the work is done by you.

Input Schema

NameRequiredDescriptionDefault
briefYesThe design brief, in the user's terms plus anything you clarified with them.
titleNoA short name for the design.
session_idNoThe project (web session) to put this design in: the session_id an earlier design of this board returned. Without it, a design whose title matches a project you opened before joins that project.
new_projectNoStart a new project even when one with this title exists.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / new_project
      Added value: +{
+  "description": "Start a new project even when one with this title exists.",
+  "type": "boolean"
+}
    • addedInput schema / properties / session_id
      Added value: +{
+  "description": "The project (web session) to put this design in: the session_id an earlier design of this board returned. Without it, a design whose title matches a project you opened before joins that project.",
+  "pattern": "^[A-Za-z0-9_-]{8,80}$",
+  "type": "string"
+}
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare non-read-only, non-destructive, closed-world. The description adds genuinely new behavioral facts: no generation quota is consumed and the generation work is performed by the calling agent, plus downstream effects (design_id consumed by every other tool, web_url for the user). It stops short of describing failure modes or project-collision behavior, which live only in the schema.

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?

Two tight sentences; the action and its inputs come first, then the return values, then the quota note. No sentence is filler, and the quota remark earns its place by changing how the agent plans its work.

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

Completeness4/5

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

There is no output schema, and the description covers that gap by naming both return values (design_id, web_url). With four params and 100% schema coverage, the only unaddressed area is project/session behavior, which the schema itself documents adequately.

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 the baseline is 3. The description earns above that by expanding what belongs in 'brief' (interfaces, power, size, constraints) beyond the schema's terser 'user's terms plus anything you clarified', giving the agent concrete content guidance for the critical required parameter.

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

Purpose4/5

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

States a specific verb and resource ('Start a new design from the user's brief') and enumerates the brief's required dimensions, plus what it returns. It does not differentiate itself from the similarly-named sibling start_board, which is the main ambiguity an agent could hit.

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

Usage Guidelines3/5

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

The phrase 'from the user's brief' and 'the work is done by you' imply this is the entry point the agent drives itself, but there is no explicit when-to-use / when-not-to-use statement and no named alternative (e.g., restore_design for existing work or start_board). The guidance is implied rather than stated.

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

All Koppar toolsInspect
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