Skip to main content
Glama
ALSO Cloud Marketplace MCP Server

ALSO Cloud Marketplace MCP Server

by pitwch

Create user

create_user

Creates a new user under a selected parent account using a supplied userAccount payload, enabling account setup and user management through the ALSO Cloud Marketplace API.

Instructions

WRITE: CreateUser under selected parent. Pass userAccount object.

Input Schema

NameRequiredDescriptionDefault
userAccountYesUserAccount payload

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior2/5

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

The "WRITE:" prefix largely restates the annotations (readOnlyHint=false), so it adds no new information. With openWorldHint=true and a user-creation mutation, the description never mentions side effects (invitations, provisioning), required permissions, idempotency, or what happens on failure — the highest-value disclosures are missing.

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?

Two short sentences, front-loaded with the mutation marker and the scoping constraint. Nothing is wasted, though it is telegraphic to the point of being under-specified rather than tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an open-world mutation taking an unconstrained nested object as its only argument and returning no documented output, the description says almost nothing about the payload shape or consequences. An agent could form the call but could not anticipate what it will do or return.

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 there is a single required parameter, so the schema already carries the contract; the description only repeats "Pass userAccount object". Given the payload is a free-form nested object (additionalProperties, no field list), the description could have named expected keys but does not.

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 clear verb and resource ("CreateUser") plus a scoping constraint ("under selected parent"), which is enough to tell it apart from update_user and create_company in the sibling list. It stops short of explaining what a "parent" is or what kind of user is created, but the core action is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"under selected parent" hints at a prerequisite but never states when to use this versus update_user, nor what must exist beforehand. There are no when-not conditions and no named alternative for the adjacent update path.

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