Skip to main content
Glama
Sign In
Anythink-MCP

Anythink-MCP

Official
by anythink-cloud
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Remote

Create a project

projects_create

Create a dedicated, isolated Anythink backend instance with its own database, API, auth, and storage. Requires a platform login and active billing; poll until Active, then connect.

Instructions

Provision a new project — a dedicated, isolated Anythink backend instance with its own database, API, auth, and storage. Requires platform login and an active billing account (set one with 'accounts_use'). Provisioning runs asynchronously: the project starts in a Provisioning state, so poll 'projects_list' until it is Active. Returns the new project's id, name, org id, and API URL. Connect to it with 'projects_use'.

Input Schema

NameRequiredDescriptionDefault
nameYesHuman-readable project name, e.g. 'production' or 'my-app'
planIdYesPlan id (UUID) that sets the project's resource tier and pricing. Run the 'plans' CLI command (via the 'cli' tool) to list available plan ids.
regionNoDeployment region slug, e.g. 'lon1'. Defaults to 'lon1'. Choose the region closest to your users.lon1
accountIdNoBilling account id to create the project in. Defaults to the active account set via 'accounts_use'.
descriptionNoOptional free-text description shown in the dashboard

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.2.27
    • removedInput schema / description
      Removed value: -"Provision a new project — a dedicated, isolated Anythink backend instance with its own database, API, auth, and storage. Requires platform login and an active billing account (set one with 'accounts_use'). Provisioning runs asynchronously: the project starts in a Provisioning state, so poll 'projects_list' until it is Active. Returns the new project's id, name, org id, and API URL. Connect to it with 'projects_use'."
    • changedInput schema / properties / accountId / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • changedInput schema / properties / description / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • removedInput schema / title
      Removed value: -"projects_create"
  2. Changed6 schema fields changedv0.2.21
    • changedInput schema / description
      Previous value: -"Create a new project in the active billing account"New value: +"Provision a new project — a dedicated, isolated Anythink backend instance with its own database, API, auth, and storage. Requires platform login and an active billing account (set one with 'accounts_use'). Provisioning runs asynchronously: the project starts in a Provisioning state, so poll 'projects_list' until it is Active. Returns the new project's id, name, org id, and API URL. Connect to it with 'projects_use'."
    • changedInput schema / properties / accountId / description
      Previous value: -"Billing account ID (uses active account if omitted)"New value: +"Billing account id to create the project in. Defaults to the active account set via 'accounts_use'."
    • changedInput schema / properties / description / description
      Previous value: -"Project description (optional)"New value: +"Optional free-text description shown in the dashboard"
    • changedInput schema / properties / name / description
      Previous value: -"Project name"New value: +"Human-readable project name, e.g. 'production' or 'my-app'"
    • changedInput schema / properties / planId / description
      Previous value: -"Plan ID (UUID) — use 'plans' CLI command to list available plans"New value: +"Plan id (UUID) that sets the project's resource tier and pricing. Run the 'plans' CLI command (via the 'cli' tool) to list available plan ids."
    • changedInput schema / properties / region / description
      Previous value: -"Deployment region (e.g. lon1)"New value: +"Deployment region slug, e.g. 'lon1'. Defaults to 'lon1'. Choose the region closest to your users."
  3. First observedv0.2.6

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare destructiveHint=false, so the description carries the real behavioral load — and it does: asynchronous provisioning, a Provisioning intermediate state, auth and billing prerequisites, and the exact return fields. That is well beyond what the structured fields provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, each front-loading the most consequential information in order: what it is, what it requires, how it behaves, what it returns and how to proceed. No filler or repetition.

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?

With no output schema, the description supplies the return shape (id, name, org id, API URL), and its coverage of async state and prerequisites is complete enough for correct invocation. Nothing an agent needs before calling is missing.

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 the schema already documents all five parameters including defaults like region='lon1' and accountId from accounts_use. The description adds no parameter syntax or format detail beyond that, so baseline 3 applies.

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?

States a specific verb+resource ('Provision a new project') and then defines what that resource actually is — an isolated backend instance with its own database, API, auth, and storage. An agent can immediately distinguish this from siblings like projects_list, projects_use, and projects_delete.

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?

Gives explicit prerequisites (platform login, active billing account, with the sibling 'accounts_use' named as the way to set one), the required follow-up ('poll projects_list until Active'), and the connection step ('projects_use'). This routes the agent through the whole lifecycle, not just the call.

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