EaseWeb

Create a project

create_project

Create a project of yours, optionally putting some of your presentations into it (in this order). A presentation is in one project at most: one that is in another project moves over.

Input Schema

TableJSON Schema

Name	Required	Description
`title`	Yes	Title (at most 100 characters).
`description`	No	Description (optional).
`presentations`	No	Slugs of presentations.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes
`url`	No	The address people open in a browser.
`role`	No	owner, edit, view or null.
`slug`	Yes	The address of the project: /project/<slug>/.
`owner`	No
`title`	Yes
`access`	No	open, public or private: inherited by its presentations.
`grants`	No	Who was given access (the owner sees it).
`is_owner`	No
`description`	No
`presentations`	No	Its presentations, in order.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 29, 2026

addedOutput schema / properties / access

Added value: +{
+  "description": "open, public or private: inherited by its presentations.",
+  "type": "string"
+}

addedOutput schema / properties / grants

Added value: +{
+  "description": "Who was given access (the owner sees it).",
+  "items": {
+    "properties": {
+      "role": {
+        "type": "string"
+      },
+      "since": {
+        "description": "ISO 8601 date and time.",
+        "type": "string"
+      },
+      "user": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}

AddedSep 29, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations declare a non-readonly, non-destructive, non-idempotent write, but they cannot express the side effect the description supplies: a presentation already in another project is moved out of it. That cross-resource mutation is exactly the kind of context annotations miss, though permissions/limits are not mentioned.

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?

Two sentences, zero filler, and the primary action is front-loaded before the optional-parameter and side-effect details. Every clause carries information the caller needs.

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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. The description covers the notable side effect; only ownership/permission requirements for creating in a workspace are left unstated.

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 100%, so the baseline is 3, but the description adds real meaning beyond the schema: the presentations array is consumed 'in this order', and the one-project-per-presentation constraint governs which slugs are valid inputs.

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 specific verb+resource ('Create a project') plus scope ('of yours') and the optional inclusion of presentations. It distinguishes itself from update_project/get_project only implicitly via the create framing and the move-over behavior; no sibling is named outright.

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

Usage Guidelines3/5

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

The create framing implies when to use it versus update_project, but there is no explicit when-to-use, when-not-to-use, or alternative routing. The move-over sentence is behavioral, not usage guidance, so the agent must infer the boundary.

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

All EaseWeb 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?