Skip to main content
Glama
Sign In

Workspace369

by com.workspace369
OverviewDiscussionsAdmin

Get team member availability

team_member_availability_get
Read-onlyIdempotent

Read a team member's weekly working hours. member_id selects one member; omit it for the whole roster. All seven days are always returned; active: false is a non-working day. Slot times are wall-clock times in time_zone; time_zone_source is member (their own zone), workspace, or default (a UTC fallback nobody set). Read-only. Returns members; change hours with team_member_availability_set.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "team_member_availability_get"
  }
}

Input Schema

NameRequiredDescriptionDefault
member_idNoTeam member id; omit for the whole roster. Use the `id` that team_members_list returns.

Output Schema

NameRequiredDescriptionDefault
membersYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / member_id / description
      Previous value: -"Team member id; omit for the whole roster."New value: +"Team member id; omit for the whole roster. Use the `id` that team_members_list returns."
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, and non-destructive behavior, so the description adds useful semantics beyond the structured safety profile: all seven days returned, active:false meaning, wall-clock slot interpretation, and time_zone_source values. It does not cover error behavior or pagination, but output schema exists.

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?

The description is front-loaded with purpose and scope, then layers return semantics and the sibling alternative. Every clause earns its place with no repetition or filler.

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

Completeness5/5

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

Given the simple one-parameter read operation, existing output schema, and read-only annotations, the description provides enough context for correct invocation: what is returned, day semantics, time-zone semantics, and the mutation alternative. No important gaps remain.

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 the member_id parameter is already fully documented in the schema. The description reinforces its effect but adds no syntax, format, or edge-case detail beyond what the schema provides, making the baseline 3 appropriate.

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?

The description states a specific verb and resource: read a team member's weekly working hours. It distinguishes member-scoped reads from whole-roster reads and explicitly names team_member_availability_set as the mutation sibling, so an agent can route correctly without opening schemas.

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?

It clearly explains member_id selection versus omission for the whole roster, and it names the sibling tool to use when changing hours. It does not compare against adjacent read tools like team_member_activity_list or calendar_check_availability, so it is clear but not fully alternative-aware.

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

All Workspace369 toolsInspect
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