Skip to main content
Glama

create_page

Create a new page. The page is automatically assigned to a folder based on:

  1. Explicit folder_id (if provided)

  2. Parent page's folder (if parent_id provided)

  3. Working directory (if cwd provided) - auto-creates folder if needed

IMPORTANT: For root pages (no parent_id), this tool automatically checks if a page already exists with the same root_path or repo_url. If found, it returns the existing page instead of creating a duplicate.

Example - simple page creation with auto-folder: create_page(title="Bug Notes", cwd="/path/to/project") -> Creates page, auto-creates "project" folder if needed

Example - sub-page (inherits folder from parent): create_page(title="API Docs", parent_id="")

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cwdNoCurrent working directory - used to auto-detect/create folder
tagsNoPage tags for categorization. Preset: documentation, architecture, testing, feature, decision, tasks, reference. Custom tags also allowed.
typeNoPage type. 'page' (default) for regular pages, 'dataspace' for structured agent data pages with datastore/state/log blocks.
titleYesTitle of the new page
repo_urlNoGit repository URL (e.g., https://github.com/user/repo)
folder_idNoOptional folder ID to assign the page to
parent_idNoOptional parent page ID - inherits folder from parent
root_pathNoCodebase root path (local filesystem)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are present, so the description carries the burden. It discloses important non-obvious behavior: folder precedence, auto-creation of folders, and the fact that root pages with matching root_path or repo_url return an existing page instead of creating a duplicate. This goes well beyond the schema, though it does not cover auth or return format.

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 structured with a numbered precedence list and two illustrative examples. It is longer than a minimal definition, but each sentence adds behavioral value and the most important caveat is called out with 'IMPORTANT'.

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?

For a create tool with 8 parameters, no annotations, and no output schema, the description covers the non-obvious folder resolution and deduplication behavior that an agent must know to call the tool correctly. It does not describe return values or explicitly compare against sibling tools, but these are not critical to correct invocation.

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 baseline is 3. The description adds significant meaning by explaining the precedence among folder_id, parent_id, and cwd, and by linking root_path/repo_url to the duplicate check. These relationships are not inferable from the individual parameter descriptions in 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 opens with 'Create a new page' and then details the specific behaviors of folder assignment and duplicate suppression. This clearly distinguishes the tool from siblings like create_block, create_page_link, update_page, and delete_page.

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 concrete when-to-use context: creating a page with automatic folder resolution via folder_id, parent_id, or cwd, including auto-creation of folders. It also warns about the idempotent duplicate-return behavior. It does not explicitly name alternatives or exclusions, but the context is clear.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources