Skip to main content
Glama
hybriden

Paperboy CMS

Official
by hybriden
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

create_user

Create an instance-wide CMS user account for admin sign-in with email, password, and roles; share the password out of band so the user can update it.

Instructions

Create a CMS user account that signs in to the admin with this email and password (instance-wide, all sites). Admin only; needs a token not limited to one site. Returns {id}. Share the password with the person out of band; they can change it and enable 2FA themselves.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesDisplay name, e.g. 'Kari Nordmann'.
siteNoSite slug or id to act in (multisite). Omit to use this server's default site. Call list_sites to see what exists — an empty tree or search usually means the wrong site, not missing content.
emailYesSign-in email address; must be unique.
rolesYesAdmin = everything; Editor = all content + publish + form submissions; Author = write content within its sections; Viewer = read-only.
passwordYesInitial password, at least 10 characters.
sectionsNodocumentIds of top-level pages this user is limited to (its subtree). Omit or [] for the whole site.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.1.3
    • addedInput schema / properties / email / description
      Added value: +"Sign-in email address; must be unique."
    • addedInput schema / properties / name / description
      Added value: +"Display name, e.g. 'Kari Nordmann'."
    • addedInput schema / properties / password / description
      Added value: +"Initial password, at least 10 characters."
    • addedInput schema / properties / roles / description
      Added value: +"Admin = everything; Editor = all content + publish + form submissions; Author = write content within its sections; Viewer = read-only."
    • addedInput schema / properties / sections / description
      Added value: +"documentIds of top-level pages this user is limited to (its subtree). Omit or [] for the whole site."
  2. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnly=false, destructive=false, idempotent=false), and the description meaningfully extends it with auth requirements (admin-only, instance-wide token), the return shape ('Returns {id}'), and operational guidance on password transfer and self-service 2FA. This is real context beyond the structured fields, though rate limits or error behavior are unaddressed.

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?

Front-loaded with the core purpose, then credential, return, and password-handling details in tight succession. Every sentence contributes, and there is no redundant restatement. Slightly dense but well structured.

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 6-parameter, 4-required mutation with no output schema and no annotations beyond hints, the description covers purpose, authorization prerequisites, return value, and post-creation password handling. It is close to self-sufficient, with only edge-case behavior (validation failures, duplicate email) left implicit.

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%, so all six parameters are already documented in the schema (roles, sections, site, etc.). The description repeats the email/password concept and clarifies the instance-wide site scope but adds no new parameter semantics. Baseline 3 applies when the schema carries the load.

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+resource ('Create a CMS user account') and adds scope ('instance-wide, all sites'), which cleanly separates it from content CRUD siblings like create_content. It does not explicitly name the adjacent user-management siblings (update_user, list_users), so it stops short of full differentiation.

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 clear preconditions for use: 'Admin only; needs a token not limited to one site.' This tells the agent when it is permitted and what credential scope is required, effectively acting as an exclusion. It doesn't name an alternative tool or fallback, but the context is unambiguous.

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

Deploy Server

Other Tools