TeamShared

Work Create

work_create

Create a work item. Created active immediately for humans and agents (no approval queue).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`repo`	No	Optional workspace slug tag
`tags`	No	Optional tags
`agent`	No	Override agent identity
`title`	Yes	Short task title
`due_at`	No	Optional due datetime
`github`	No	Optional owner/repo tag
`part_of`	No	Ontology entity this beat belongs to (campaign Project name)
`priority`	No	urgent, high, normal, low	normal
`start_at`	No	Optional start datetime
`item_type`	No	task, milestone, or approval	task
`parent_id`	No	Parent task UUID (makes this a subtask)
`project_id`	No	Add the task to this project UUID
`section_id`	No	Place in this project section UUID
`assignee_id`	No	Assignee UUID
`description`	No	Alias for description_md
`work_status`	No	Initial workflow status	todo
`assignee_type`	No	Assignee type (user)
`initiative_id`	No	Optional strategic initiative UUID
`playbook_slug`	No	Named playbook to inject when agent_run_start(work_id=) spawns (e.g. teamshared-manager). Unset = no inject
`assignee_email`	No	Assign to org member by email
`description_md`	No	Optional markdown body
`assigned_to_entity`	No	Ontology Person or Agent name (graph assigned_to; not assignee_email)

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed1 schema field changedSep 1, 2026

addedInput schema / properties / playbook_slug

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Named playbook to inject when agent_run_start(work_id=) spawns (e.g. teamshared-manager). Unset = no inject"
+}

Changed2 schema fields changedAug 30, 2026

addedInput schema / properties / assigned_to_entity

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Ontology Person or Agent name (graph assigned_to; not assignee_email)"
+}

addedInput schema / properties / part_of

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Ontology entity this beat belongs to (campaign Project name)"
+}

First observedAug 18, 2026

TDQS

B3.2/5.0

Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It does disclose one genuinely useful trait — items become active immediately with no approval queue — which matters for an agent deciding whether created items will take effect right away. It does not disclose other side effects of mutation, such as visibility persistence or whether creation is reversible, but the immediate-activation note is meaningful.

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?

Two sentences with no filler, and the core action is front-loaded. The phrase 'Created active immediately' is slightly awkward grammatically, but the size is appropriate and every clause earns its place.

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?

The output schema relieves the description of explaining return values, and the activation behavior is covered. However, for a 22-param mutation tool with zero annotations, the description is thin: it doesn't hint at the breadth of configuration options (parenting, projects, playbooks, initiative linking) or any side effects beyond immediate activation. Adequate but not rich.

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 coverage is 100%, so every parameter is already documented in the schema and the baseline of 3 applies. The description adds no parameter-level meaning beyond what the schema provides; it does not, for example, clarify which options interplay with the activation behavior.

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?

The description states a specific verb and resource — 'Create a work item' — which clearly distinguishes this from sibling work_* tools like work_update, work_get, and work_close. It doesn't elaborate that a work item encompasses tasks, milestones, and approvals (that's left to the item_type parameter), but the core purpose is 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 use this tool versus alternatives. Among 22 siblings in the work_* family there is no mention of when to choose work_create over work_add_to_project or work_update, and no prerequisites are stated. The activation note is behavioral, not usage guidance.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.4/5.0

Disambiguation4/5

With 104 tools across many domains (memory, work, projects, files, agents, context, strategic, ontology), the use of clear prefixes (memory_, work_, project_, file_, agent_run_, context_) makes most tools distinct. However, there are some potential confusions between memory_session_* vs memory_state_*, and memory_recall vs memory_think vs memory_assemble_context, though descriptions clarify their specific purposes. Aliases like memory_playbook_get for memory_procedure_get are explicit and reduce ambiguity.

Naming Consistency5/5

Tool names follow a highly consistent pattern: prefix_domain_action (e.g., file_create, work_update, memory_recall, agent_run_start). All use snake_case, with verbs consistently placed after the domain prefix. Even less common tools like account_brief and attention_snapshot fit the overall naming scheme, making the set predictable and easy to navigate.

Tool Count3/5

At 104 tools, this is an exceptionally large surface area, far exceeding the 25+ threshold that feels heavy. However, the server covers an extensive domain (organizational memory, work management, project tracking, file sharing, agent orchestration, and strategic planning), which justifies a large count. Still, the sheer number may overwhelm agents, and some tools could be consolidated (e.g., many memory_session_* and memory_state_* variants).

Completeness4/5

The tool surface is remarkably complete for its stated purpose, covering CRUD operations for files, work items, projects, and memory, plus lifecycle management for agents, sessions, and strategic plans. Minor gaps exist (e.g., no direct memory_item_get by ID, no section removal in projects), but agents can work around these using existing tools like memory_recall or work_create with parent_id. Overall, the set minimizes dead ends.

Work Create

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

TDQS

Resources