AnalyticsProof

Create a project

create_project

Create a project (permission: admin)

Create a project in the calling org key's org, as from the dashboard; it takes the org's plan. A project key answers 403 org_key_required. A cancelled org answers 409 org_cancelled. An agent connection (OAuth access token) creates the user's personal project (one free project per user: a second answers 402 free_project_limit; an eligible user gets the Starter trial), or with orgId a project in an organization the user administers. Idempotency-Key has the slot per org, or per user for a personal project (there is no project yet): the same request replays the 201, another request under the same key is 422 idempotency_conflict. idempotencyKey (sent as the Idempotency-Key header): retrying the same call with the same value replays the original answer; the same value with different arguments is 422 idempotency_conflict, and 409 idempotent_in_progress means wait error.meta.retryAfter seconds and retry.

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

Input Schema

Name	Required	Description
`name`	Yes	The project name (1-100 characters).
`orgId`	No	Agent connections only: create the project in this organization, which you administer; omitted, your personal project.
`idempotencyKey`	No	Optional Idempotency-Key: reuse the same value when retrying this exact call so it is applied once.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 5, 2026

addedInput schema / properties / name / description

Added value: +"The project name (1-100 characters)."

addedInput schema / properties / orgId / description

Added value: +"Agent connections only: create the project in this organization, which you administer; omitted, your personal project."

First observedNov 4, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false) by enumerating the actual failure modes with their status codes and machine-readable error identifiers. It explains the idempotency-key slot semantics (per org vs per user), the 201 replay, 422 idempotency_conflict, and the 409 idempotent_in_progress retryAfter wait. The non-idempotent annotation is consistent with the opt-in key mechanism described.

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

Conciseness3/5

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

The core statement is front-loaded and the error-code detail is genuinely useful, but the idempotency behavior is explained twice in near-identical terms ('Idempotency-Key has the slot per org...' followed by the idempotencyKey parenthetical), and the whole body is one dense paragraph of semicolon-chained clauses. Tightening the duplication and splitting the error catalog from the happy path would materially help.

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 three-parameter mutation with no output schema and no annotations, the description covers permissions, tenancy resolution, quotas, and every documented error path. The only residual gap is the success payload: it tells the agent a 201 is replayed but not what the created project object looks like.

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

Parameters4/5

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

Schema coverage is already 100%, so baseline would be 3, but the description adds real meaning: orgId is agent-connection-only and must be an org the user administers, and idempotencyKey is transmitted as the Idempotency-Key header with replay/conflict consequences. The name parameter's 1-100 constraint is left to the schema, which is fine.

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 ('Create a project') and immediately qualifies scope: it lands in the calling org key's org, or the user's personal project for agent connections. This distinguishes it cleanly from list_projects and the other read/create siblings without opening any schema.

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 explicit preconditions and exclusions: requires admin permission, fails with 403 org_key_required for project keys, 409 org_cancelled for cancelled orgs, 402 free_project_limit for a second personal project. It also scopes orgId to agent connections administering an org. It does not name an alternative tool for the org-key case, which keeps it just short of a 5.

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

All AnalyticsProof tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?