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

For a project with an organization template, first call get_project_organization(project_root_id). Choose a section using its purpose and the page content, then pass organization_placement: {mode: "section", project_root_id: "...", expected_binding_revision: 1, section_key: "..."} Omit parent_id: core resolves the section and creates only missing section pages on that path. To reuse an existing section page, explicitly include it in anchor_page_ids. Only if the user requests an exception, use mode: "user_override" with their reason and a parent_id inside the same project (omit parent_id to use the project root). This workflow makes no server-side LLM call. Placement is the agent's decision.

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="<parent_page_id>")

Input 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)
organization_placementNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / $defs
      Added value: +{
      +  "SectionPlacement": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "anchor_page_ids": {
      +        "maxProperties": 6,
      +        "patternProperties": {
      +          "^[a-z][a-z0-9_.-]*$": {
      +            "format": "uuid",
      +            "type": "string"
      +          }
      +        },
      +        "propertyNames": {
      +          "maxLength": 120,
      +          "minLength": 1
      +        },
      +        "title": "Anchor Page Ids",
      +        "type": "object"
      +      },
      +      "expected_binding_revision": {
      +        "minimum": 1,
      +        "title": "Expected Binding Revision",
      +        "type": "integer"
      +      },
      +      "mode": {
      +        "const": "section",
      +        "title": "Mode",
      +        "type": "string"
      +      },
      +      "project_root_id": {
      +        "format": "uuid",
      +        "title": "Project Root Id",
      +        "type": "string"
      +      },
      +      "section_key": {
      +        "maxLength": 120,
      +        "minLength": 1,
      +        "pattern": "^[a-z][a-z0-9_.-]*$",
      +        "title": "Section Key",
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "mode",
      +      "project_root_id",
      +      "expected_binding_revision",
      +      "section_key"
      +    ],
      +    "title": "SectionPlacement",
      +    "type": "object"
      +  },
      +  "UserOverridePlacement": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "expected_binding_revision": {
      +        "minimum": 1,
      +        "title": "Expected Binding Revision",
      +        "type": "integer"
      +      },
      +      "mode": {
      +        "const": "user_override",
      +        "title": "Mode",
      +        "type": "string"
      +      },
      +      "project_root_id": {
      +        "format": "uuid",
      +        "title": "Project Root Id",
      +        "type": "string"
      +      },
      +      "reason": {
      +        "maxLength": 1000,
      +        "minLength": 1,
      +        "title": "Reason",
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "mode",
      +      "project_root_id",
      +      "expected_binding_revision",
      +      "reason"
      +    ],
      +    "title": "UserOverridePlacement",
      +    "type": "object"
      +  }
      +}
    • addedInput schema / properties / organization_placement
      Added value: +{
      +  "discriminator": {
      +    "mapping": {
      +      "section": "#/$defs/SectionPlacement",
      +      "user_override": "#/$defs/UserOverridePlacement"
      +    },
      +    "propertyName": "mode"
      +  },
      +  "oneOf": [
      +    {
      +      "$ref": "#/$defs/SectionPlacement"
      +    },
      +    {
      +      "$ref": "#/$defs/UserOverridePlacement"
      +    }
      +  ]
      +}
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the burden well: it discloses the folder resolution order, that folders may be auto-created, that duplicate root_path/repo_url pages return the existing page instead of creating one, and that no server-side LLM call occurs. Still missing: required permissions/scope, what the response contains (e.g., new page id), and how expected_binding_revision staleness is handled.

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?

Core purpose and folder precedence are front-loaded, then the organization workflow, then examples — a sensible ordering. It is longer than average and repeats the parent_id guidance twice, plus two example blocks, but the complexity of the placement protocol largely justifies the length.

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 9-parameter creation tool with no output schema and no annotations, the description covers the hard part (placement resolution and duplicate avoidance) thoroughly. The remaining gap is what happens on success — return shape, id retrieval for follow-up calls, and the meaning/refresh path for expected_binding_revision.

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 89% so the baseline is 3, but the description adds real semantics beyond the schema: the precedence among folder_id / parent_id / cwd, the shape of organization_placement with its modes, and the meaning of anchor_page_ids for reusing existing section pages. expected_binding_revision and the dataspace 'type' value receive no explanatory treatment in the description.

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?

Opens with a specific verb+resource ('Create a new page') and immediately scopes the secondary behavior (automatic folder assignment) with an ordered precedence list. It does not explicitly contrast with update_page or create_block, but the dedup note about root_path/repo_url makes the creation semantics distinct enough for an agent to identify it.

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?

Explicitly states the prerequisite (first call get_project_organization), when to use section mode, when to omit parent_id, when to add anchor_page_ids, and reserves user_override for explicit user-requested exceptions. This is a genuine when/when-not/alternative routing guide with an example call sequence.

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