Skip to main content
Glama

Open a new project

arroway_start_project

Open a NEW project when the work has no home; it needs slug, name and scope. Propose them to the person FIRST. update=true renames a project you own and rewrites its scope when the person asks or the scope is wrong; the slug stays. invite brings someone in by email.

Input Schema

NameRequiredDescriptionDefault
nameNoHow people will call it
slugYesShort, lowercase, hyphenated, unique — e.g. 'trading-solana'
scopeNoWhat belongs here and what does not: the subject AND what is out.
inviteNoEmail of a person to bring in. Returns a checkout link if a team plan is needed.
updateNotrue: change name and scope of the existing project at slug.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / invite / description
      Previous value: -"Email of a person to bring in; name and scope not needed. Returns a checkout link if a team plan is needed."New value: +"Email of a person to bring in. Returns a checkout link if a team plan is needed."
  2. Changed2 schema fields changed
    • addedInput schema / properties / invite
      Added value: +{
      +  "description": "Email of a person to bring in; name and scope not needed. Returns a checkout link if a team plan is needed.",
      +  "maxLength": 200,
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "slug",
      -  "name",
      -  "scope"
      -]New value: +[
      +  "slug"
      +]
  3. Changed1 schema field changed
    • addedInput schema / properties / update
      Added value: +{
      +  "description": "true: change name and scope of the existing project at slug.",
      +  "type": "boolean"
      +}
  4. Changed6 schema fields changed
    • removedInput schema / properties / name / minLength
      Removed value: -1
    • changedInput schema / properties / scope / description
      Previous value: -"What belongs here and what does not. Written for the next assistant to read before writing — say the subject AND name what is out."New value: +"What belongs here and what does not: the subject AND what is out."
    • removedInput schema / properties / scope / minLength
      Removed value: -1
    • removedInput schema / properties / slug / minLength
      Removed value: -1
    • removedInput schema / properties / slug / pattern
      Removed value: -"^[a-z0-9]+(?:-[a-z0-9]+)*$"
    • removedInput schema / x-maxSerializedLength
      Removed value: -131072
  5. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Beyond the annotations (readOnly=false, destructive=false), it discloses that update rewrites scope, that the slug is immutable on rename, that ownership is required, that invite can return a checkout link for a team plan, and that parameters should be confirmed with the person first. Notably, rewriting an existing scope is a lossy overwrite that destructiveHint=false does not signal, and the description only half-compensates by saying "rewrites its scope".

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?

Roughly three compact sentences, front-loaded with the primary create action, then the update and invite modes. Slight terseness in "it needs slug, name and scope" and "Propose them to the person FIRST" reads as clipped, but nothing is padded.

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?

With five parameters, no output schema, and annotations already covering safety, the description covers every parameter's intent plus the precondition of confirming values with the person. It omits failure behavior (e.g. slug collision on create, update against an unowned project), which is the main remaining gap.

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 coverage is 100%, so the schema already documents all five parameters and the baseline is 3. The description still adds real meaning the schema lacks: update implies the slug stays fixed, and invite's email produces a checkout link when a team plan is required.

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?

"Open a NEW project" gives a specific verb and resource, and the description explicitly separates the create path from the in-tool update and invite modes. It never names or contrasts a sibling tool (e.g. arroway_move or arroway_claim), so an agent comparing this against the other 17 arroway_* tools gets no help from the text alone.

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?

"when the work has no home" is a clear use condition, and update has its own trigger ("when the person asks or the scope is wrong"). It also prescribes an interaction pattern: propose slug, name, and scope to the person FIRST. No when-not guidance or alternative tool is offered, which keeps it off 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