Skip to main content
Glama

create_collection

Destructive

Creates a new documentation collection in the organization together with its invisible root page (type 0), auto-assigns collection permissions to all org users based on their roles, and auto-provisions an MCP server for it in the background. The returned rootParentId is the page id under which top-level pages are created (via Create Page). SSO read-only organizations that already have a collection get 403. Slug is permanent; if omitted it is derived from the name. A chosen slug that is taken returns 409, and a chosen slug that is one of docstar-cli's own commands (reserved) returns 400. A body that fails validation returns 400 with the Joi message. Body fields:

name (string, required) - Collection name, 3-55 characters. If the organization already has a collection with the same name (or a name like "name_N"), a numeric suffix is appended to the stored name (for example "Docs_2") instead of an error. slug (string, optional) - Permanent URL-safe identifier: lowercase letters, numbers and underscores only (no hyphens or spaces; 2-50 chars). Cannot be changed later. It is what docstar-cli (docstar-cli ...) and the MCP URL are built on, so these reserved words can't be chosen (400 "This slug is reserved, please choose another one"): alias, auth, clean, complete, completion, completion-script, config, help, init, key, list, login, logout, mcp. If omitted it is derived from the name (every run of other characters becomes an underscore), with a random suffix added when that slug is already taken or reserved. description (string, optional) - Collection description (null or empty allowed). isPublic (boolean, optional) - Accepted but ignored on create: a new collection is always created with isPublic true. Use Update Collection to change it. type (string, optional) - Collection type: 'page' (default, documentation pages), 'api' (API reference), 'blog', or 'embed'. customDomain (string, optional) - Custom domain to serve the public docs on, e.g. docs.example.com. Must be unique. path (string, optional) - Path prefix under the custom domain, e.g. 'api'. theme (string, optional) - Theme/brand color hex string, default '#f2994a'. favicon (string, optional) - Favicon URL. gtmId (string, optional) - Google Tag Manager ID. docProperties (object, optional) - Free-form doc settings object, e.g. {"languages":["hi","fr"]} for AI translations. environment (object, optional) - Accepted but ignored on create: the stored environment is always null. Set it with Update Collection. meta (object, optional) - Free-form metadata object. orgDetails (object, optional) - Organization display details object (overwritten with the organization name on create). runCollection (object, optional) - Landing page (run collection) data object. uniqueTabId (string, optional) - Optional browser tab id used only to suppress the realtime socket echo to the calling tab; agents can omit it. POST https://api.docstar.io/orgs/:orgId/collections

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": {
      "orgId": "<orgId>"
    },
    "name": "create_collection"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoe.g. Payments API Docs
slugNoe.g. payments_api_docs
typeNoe.g. api
orgIdYesThe orgId path variable
descriptionNoe.g. Public docs for the Payments API

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare the generic write profile (readOnlyHint=false, destructiveHint=true); the description adds substantial non-obvious behavior: permissions are auto-assigned to all org users by role, an MCP server is provisioned in the background, slug is permanent and drives the MCP URL, duplicate names get a numeric suffix instead of erroring, and isPublic/environment are silently ignored on create. It also documents the return value (rootParentId) despite no output schema.

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?

Well front-loaded: purpose and side effects come first, then error semantics, then a per-field breakdown. It is long, and the exhaustive reserved-slug enumeration and the explicit REST endpoint line are somewhat heavy, but nearly every sentence carries decision-relevant information.

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 mutation with no output schema, the description supplies everything an agent needs: side effects, permission model, permanence constraints, the concrete error codes it must handle, which fields are no-ops, and the meaning of the returned rootParentId.

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

Parameters5/5

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

Schema description coverage is nominally 100%, but the actual schema only exposes 5 shallow properties with example-only descriptions, while the description documents the full body including constraints (name 3-55 chars, slug 2-50 lowercase/underscore only), reserved-word collisions, mutability (slug permanent, cannot be changed), and fields that are accepted-but-ignored. This meaningfully exceeds what the schema conveys.

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?

Opens with a specific verb+resource ("Creates a new documentation collection") and immediately enumerates the non-obvious side effects (invisible root page, permission auto-assignment, MCP server provisioning). It also names siblings it relates to ("via Create Page", "Use Update Collection"), so an agent can separate it from create_page and update_collection without inspecting schemas.

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 clear context for when this applies (new collection creation, with documented failure conditions: 403 for SSO read-only orgs that already have a collection, 409 taken slug, 400 validation/reserved slug) and redirects to Update Collection for fields that can't be set on create. It stops short of explicitly telling the agent to check list_collections first, so a 4 rather than a 5.

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