Atwork

Update a Member's Profile

member.update_profile

DestructiveIdempotent

Owner only: change another member's profile (name, job title, @handle, pronouns, bio, phone number, status, timezone, out-of-office days). Always asks the user first. For the user's own profile use profile.update.

Input Schema

Name	Required	Description
`bio`	No	Up to 280 characters; empty clears it
`job`	No	A job title from the organization's Jobs list, by name; jobs are never created here
`phone`	No	Phone number as the user wrote it: digits, spaces and + ( ) - . only, at least 3 digits; empty clears it. Who sees it is a preference.
`handle`	No	The @handle of the public profile
`member`	Yes	The member's full name, as member.read lists it
`status`	No	The status line next to the name; null clears it
`lastName`	No
`pronouns`	No	Empty clears them
`timezone`	No	IANA zone, e.g. Europe/Berlin
`firstName`	No
`outOfOffice`	No	Whole-day time off in the calendar, inclusive days; the list replaces current and future whole-day time off, past time off is kept; to: null = until further notice; null clears it

Output Schema

Name	Required	Description	Default
`saved`	Yes	Each changed field as saved
`member`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026

addedInput schema / properties / phone

Added value: +{
+  "description": "Phone number as the user wrote it: digits, spaces and + ( ) - . only, at least 3 digits; empty clears it. Who sees it is a preference.",
+  "maxLength": 32,
+  "type": "string"
+}

AddedNov 4, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Adds real context beyond the annotations: an owner-only authorization requirement and the fact that the user is prompted before the change. However, destructiveHint=true is left unelaborated – the description does not say that empty strings or nulls clear fields and that out-of-office ranges replace existing ones, which is the main risk an agent needs to know.

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 short sentences with the authorization constraint front-loaded, followed by the sibling routing hint. No filler or redundant restatement of the title.

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 an 11-parameter mutation tool with an output schema and rich annotations, this covers permissions, alternatives and field scope well. The only meaningful omission is an explanation of the destructive behaviors (clearing fields, replacing out-of-office ranges) that the destructiveHint signals but does not specify.

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 82%, so the schema already documents field formats, limits and clear semantics. The description's parenthetical field list only mirrors those parameters and adds no format or edge-case detail beyond what is structured already; baseline 3 applies.

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

Purpose5/5

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

States a specific verb and resource ('change another member's profile') and enumerates the editable fields, so the scope is unambiguous. It also explicitly contrasts with the sibling profile.update, which handles the user's own profile.

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

Usage Guidelines5/5

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

Gives the prerequisite ('Owner only') and names the alternative tool with the exact condition that selects it ('For the user's own profile use profile.update'). It also notes the confirmation step ('Always asks the user first'), leaving nothing to inference.

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

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