Skip to main content
Glama
LibreDesk MCP

LibreDesk MCP

by Passe12345

update_team_assignee

Assigns or changes the team handling a support conversation by updating its team assignee using the conversation UUID and target team ID.

Instructions

Update Team Assignee Requires the conversations:update_team_assignee permission. PUT /api/v1/conversations/{uuid}/assignee/team Tags: Conversations

Input Schema

NameRequiredDescriptionDefault
uuidYes(path parameter)
assignee_idYes(body) Team ID to assign

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

C2.3/5.0
Behavior2/5

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

No annotations are supplied, so the description carries the full behavioral burden. It usefully discloses the required `conversations:update_team_assignee` permission, but says nothing about side effects (does it clear an existing user or team assignee?), idempotency, or what is returned on success or failure. For a mutation with zero annotation coverage, this is a meaningful gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The text is short, but a large share is low-value boilerplate: the title repeated as the first line, a permission string, a raw HTTP route, and a redundant 'Tags: Conversations' line. Useful content (permission requirement, endpoint) is not front-loaded relative to the noise.

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

Completeness2/5

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

This is a mutation endpoint with no annotations and no output schema, so the description should explain the effect of the assignment and any replacement/override semantics. It supplies only the permission and route, leaving the agent unable to predict the operation's effect on existing assignments.

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 both parameters (uuid path parameter and assignee_id team ID) are already documented. The description adds no format, constraint, or sourcing detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with the title restated verbatim ('Update Team Assignee'), and the only added information is the HTTP route PUT /api/v1/conversations/{uuid}/assignee/team plus a tag line. This implies assigning a team to a conversation, but the agent learns that mostly from the parameter names, not from an explicit statement of what the tool does. It does not distinguish itself from siblings such as update_user_assignee or remove_team_assignee.

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 on when to use this tool, when to prefer update_user_assignee instead, or whether this replaces an existing user assignee. The only stated precondition is the required permission, which is a prerequisite rather than usage guidance.

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

Deploy Server

Other Tools