TeamShared

project_update

Update project metadata, lifecycle, priority, dates and lead.

Input Schema

Name	Required	Description
`name`	No	New name
`agent`	No	Override agent identity
`color`	No	Color label
`status`	No	Lifecycle: backlog, active, completed, or archived
`priority`	No	urgent, high, normal, low; empty string clears
`project_id`	Yes	Project UUID
`start_date`	No	Start date YYYY-MM-DD; empty string clears
`owner_email`	No	Lead (owner) member email; empty string clears
`target_date`	No	Target date YYYY-MM-DD; empty string clears
`default_view`	No	list/board/timeline/calendar
`initiative_id`	No	Strategic initiative UUID
`description_md`	No	New markdown body

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 19, 2026
RemovedSep 25, 2026

Changed4 schema fields changedSep 10, 2026

addedOutput schema / additionalProperties
```
Added value: +true
```

removedOutput schema / properties

Removed value: -{
-  "result": {
-    "anyOf": [
-      {
-        "additionalProperties": true,
-        "type": "object"
-      },
-      {
-        "type": "null"
-      }
-    ]
-  }
-}

removedOutput schema / required
```
Removed value: -[
-  "result"
-]
```
removedOutput schema / x-fastmcp-wrap-result
```
Removed value: -true
```

First observedAug 18, 2026

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It implies mutation but never states partial-update semantics — specifically whether an omitted field is left untouched or whether null/empty-string clears it (the schema mentions 'empty string clears' for only some fields). It also says nothing about permissions, reversibility, or side effects of a lifecycle change.

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?

A single front-loaded sentence with no filler, and the verb+resource leads. The trailing field list is mildly redundant against a 100%-covered schema but is cheap and orients the reader quickly.

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?

An output schema and fully-described parameters reduce what the description must carry, so it is close to adequate. Still, for a 12-parameter mutation tool with zero annotations, the absence of partial-update semantics and of any tie-breaker versus project_archive leaves gaps an agent must guess at.

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 each of the 12 parameters is already documented in the schema, including clearing conventions and date format. The description's field-group summary adds framing but no syntax or meaning beyond what the schema provides, so the baseline 3 applies.

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 ('Update project') and enumerates the affected field groups: metadata, lifecycle, priority, dates, lead. That is enough to distinguish it from project_create, project_get and project_list. However it does not differentiate from project_archive, despite status 'archived' overlapping with that sibling's job.

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 when-to-use guidance, no prerequisites, and no mention of alternatives. The overlap with project_archive (since 'archived' is an accepted status value here) is a real routing ambiguity the description never resolves.

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

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.