DB Planner

Create document

create_document

Create a document in a project. A project holds database schemas (DBML or SQL) and diagrams (Mermaid) side by side, and both render onto the same board. To move documents that already exist, use reorder_documents.

Input Schema

TableJSON Schema

Name	Required	Description
`kind`	No	"dbml" for a database schema (the default), "mermaid" for a diagram. Name the file to match: .dbml for a schema, .mmd for a diagram.
`name`	Yes	File name, e.g. schema.dbml or flow.mmd.
`order`	No	Sort position in the project's document list; omit to append.
`content`	No	Initial document text; omit for the kind's starter content.
`projectId`	Yes	Project id (uuid).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes
`kind`	Yes
`name`	Yes
`order`	No
`content`	Yes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 4, 2026

TDQS

A4.5/5.0

Behavior4/5

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

The annotations only provide destructiveHint=false and openWorldHint=false, so the description carries the main explanatory burden. It transparently says this is a create operation and adds useful context about schemas and diagrams rendering on the same board. It does not cover edge cases like duplicate names or whether existing content is replaced, but those are minor given the schema and non-destructive hint.

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 three sentences with no wasted words: the core action comes first, the domain context earns its place by explaining document kinds and board behavior, and the sibling routing is direct. Each sentence contributes to selection or invocation.

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?

For a 5-parameter create tool with 100% schema coverage, a non-destructive hint, and an output schema, the description provides sufficient selection context: what is created, where, and which sibling handles the related move operation. No critical information needed to invoke the tool correctly is missing.

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 all parameters have descriptions, so the baseline is 3 even though the tool description does not repeat parameter-level detail. The description's project/board context supports understanding of 'kind' and 'name' indirectly, but it does not add much beyond the schema.

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 action and resource: 'Create a document in a project.' It further distinguishes this tool from reorder_documents by explicitly naming the sibling for moving existing documents, so an agent can tell creation apart from reordering without needing to inspect the schema.

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?

The description gives an explicit when-not instruction: 'To move documents that already exist, use reorder_documents.' This directly routes the agent away from this tool for a related operation and toward the correct alternative, satisfying the usage-guidance requirement.

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

All DB Planner 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

A3.7/5.0

Disambiguation4/5

Most tools target a distinct resource and action, and the descriptions clearly explain boundaries. However, list_diagrams/list_documents and get_board/get_board_image are two pairs that both concern the same underlying resource, so an agent could initially select the wrong one without reading carefully.

Naming Consistency4/5

Nearly all tool names are snake_case verb_noun pairs such as create_project, update_document, and unpublish_listing, which is very consistent. The exceptions are bare 'draw' and the non-pattern 'whoami', so it is not a perfect 5.

Tool Count2/5

With 38 tools, the surface exceeds the 25+ threshold and spans orgs, projects, documents, board drawing, membership, and marketplace publishing. While each subdomain is individually reasonable, the aggregate is heavy and likely to overwhelm an agent; several related actions could be grouped or exposed more sparingly.

Completeness4/5

The set covers the main lifecycle: org/project/document CRUD, board rendering and editing, member management, and template publish/use/update. Minor gaps remain—there is no get_project single-resource read, and groups/links/notes are manipulated only through the generic update_board rather than dedicated tools—but these are workable.

Resources

Need Help?