MCPBinder

item create

item_create

DestructiveIdempotent

Create a project or task in the authorized workspace. Task creation can send configured webhooks and workspace notifications. For an import, set source to the item's system and ID there; find imported tasks again with get_tasks' sourceSystem and sourceIds. To create many, use items_create. Creating a project requires projects:write and whole-workspace access. A workspace owner or admin can include its workflow (statuses, labels and sections) without workflows:write; changing an existing workflow requires workflows:write. Tasks require tasks:write. Provide a unique requestId and reuse it when retrying this exact action. Item updates require the current version from get_tasks, get_items, or get_workspace. Permissions are enforced for the workspace, project, and account.

Input Schema

Name	Required	Description
`kind`	Yes
`dueOn`	No	Due date as YYYY-MM-DD: a calendar day with no time or time zone. null clears it.
`title`	Yes
`source`	No	For an import: where the project or task came from. When its system and id already name an item in this workspace, that item is returned, marked existing, instead of a duplicate, so an import can safely run again.
`status`	No	Status category. Tasks: todo, in_progress, blocked, done or skipped, which selects the project's first status in that category; use workflowStatusId for a specific custom status. Projects: planned, active, paused or complete. Resources: active or approved.
`context`	No	Projects only: goal, constraints, decisions and next actions. Each field sent replaces that field. Keep standing rules that apply to all of a project's tasks in constraints and decisions, not repeated in each task's description; get_tasks returns them with a project's first page.
`labelIds`	No	Tasks only: label IDs from the project's workflow, replacing the task's labels.
`workflow`	No	Projects only: the new project's task statuses, labels and sections, so imported tasks can use them from the start. Omit for the default statuses (todo, in_progress, blocked, done, skipped). Every status category needs at least one status. An option without an id gets one from its name, such as apply-next for Apply next. Requires a workspace owner or admin.
`projectId`	No
`requestId`	Yes
`sectionId`	No	Tasks only: a section ID from the project's workflow. null leaves it unsectioned.
`description`	No
`assigneeUserId`	No	Tasks only: a person's ID from get_workspace people. null unassigns.
`assigneeGrantId`	No	Tasks only: an agent's ID from get_workspace assignableAgents. null unassigns.
`workflowStatusId`	No	Tasks only: a status ID from the project's workflow, which get_workspace and get_items return with each project. Takes precedence over status.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 15, 2026

TDQS

A4/5.0

Behavior4/5

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

Adds substantial behavior beyond the annotations: task creation can fire webhooks and workspace notifications, requestId must be reused for idempotent retries (matching idempotentHint), and permissions are enforced per resource with owner/admin needed for inline workflows. It does not explain why destructiveHint is true or the openWorld implications, leaving a gap.

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?

Dense but front-loaded: the core action leads, then imports, bulk alternative, and permissions follow in a logical order. The trailing sentence about updates requiring a version from get_tasks/get_items/get_workspace is tangential to a create tool and does not earn its place.

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 15-parameter, nested-object, no-output-schema create tool, the description covers the important gaps: permission matrix, idempotency, import semantics and workflow requirements. The stray update/version sentence is misleading in a create context, which keeps it from a 5.

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 67%, and the description compensates by explaining cross-field semantics the schema can't: source.system/source.id drive idempotent import de-duplication, requestId is a retry key, and workflow/status/label params are project-only and permission-gated. It adds real meaning beyond the per-field descriptions.

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?

Opens with a specific verb plus resource and scope: 'Create a project or task in the authorized workspace.' It also routes the bulk case to the items_create sibling. However, it never distinguishes itself from the create_project and create_task_form siblings, which an agent could confuse with the project/task branches of this tool.

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 concrete context: set source for imports, use items_create to create many, and spells out the permission conditions that gate project, task and workflow creation. No explicit 'when not to use this vs create_project/create_task_form', so it stops 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 MCPBinder tools Inspect

Try in Browser

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?