TeamShared

project_create

Create a project (Asana-style task container).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes	Project name
`agent`	No	Override agent identity
`color`	No	Optional color label
`status`	No	Lifecycle: backlog or active (default active)
`team_id`	No	Owning team UUID
`priority`	No	urgent, high, normal, or low
`start_date`	No	Start date YYYY-MM-DD
`owner_email`	No	Lead (owner) member email
`target_date`	No	Target date YYYY-MM-DD
`default_view`	No	list, board, timeline, or calendar	list
`initiative_id`	No	Strategic initiative UUID for roll-up
`description_md`	No	Optional markdown body

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 27, 2026

changedInput schema / properties / owner_email / description

Previous value: -"Owner member email"New value: +"Lead (owner) member email"

addedInput schema / properties / priority

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "urgent",
+        "high",
+        "normal",
+        "low"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "urgent, high, normal, or low"
+}

addedInput schema / properties / start_date

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Start date YYYY-MM-DD"
+}

addedInput schema / properties / status

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "backlog",
+        "active",
+        "completed",
+        "archived"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Lifecycle: backlog or active (default active)"
+}

addedInput schema / properties / target_date

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Target date YYYY-MM-DD"
+}

First observedAug 18, 2026

TDQS

B3.3/5.0

Behavior2/5

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

There are no annotations, so the description must carry the burden of behavioral disclosure. It only says 'Create a project' and does not mention side effects, required ownership, idempotency, permission needs, or what the created resource looks like. The name alone already implies creation.

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?

The description is one short sentence with no filler. The clarifying parenthetical adds useful context without repeating schema information, and the key action is front-loaded.

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

Completeness3/5

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

For a 12-parameter creation tool with an output schema and no annotations, the one-line description is thin on behavioral and usage context. However, the schema is self-documenting for parameters and defaults, so the core invocation details are present; only the higher-level lifecycle context 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 documents all 12 parameters and their defaults. The description adds no parameter-level meaning beyond the parenthetical 'Asana-style task container,' which is a baseline contribution.

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?

The description uses a specific verb and resource ('Create a project') and clarifies what a project is ('Asana-style task container'), which distinguishes this creation tool from sibling read/update tools like project_get, project_list, and project_status_post. The resource and operation are 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?

No guidance is given on when to choose this tool over alternatives such as work_create for tasks or project_list for finding existing projects. The phrase 'Asana-style task container' hints at the domain, but the description never states conditions, prerequisites, or exclusions.

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

All TeamShared 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.