Skip to main content
Glama
Sign In
musterd

musterd

Official
by musterd-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

team_availability

Set your own availability as available, away, or do not disturb, with an optional return time for away status, so others know when you can receive notifications.

Instructions

Set your OWN availability (ADR 044): 'available', 'away' (holds notifications; pass until as an ISO time for the roster's "off until"), or 'dnd' (only urgent gets through). Explicit and self-only — never inferred, never set on your behalf. The CLI twin is musterd availability. Added 2026-09-03 (surface survey #1245): agents had no way to say they were away.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "status": "<status>"
    },
    "name": "team_availability"
  }
}

Input Schema

NameRequiredDescriptionDefault
untilNoISO time you are back — `away` only; the roster shows 'off until <t>'
statusYesyour availability

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.1

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations supplied, the description carries the full burden and does disclose behavior: `away` holds notifications, `dnd` lets only urgent traffic through, and the setting is explicit and self-scoped only. It does not say whether the state persists across sessions, expires without `until`, or what the call returns, which keeps it below a 5.

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 operative content is front-loaded and the status definitions are efficient, but the trailing provenance ("Added 2026-09-03 (surface survey #1245)") and the ADR citation consume space without helping an agent call the tool correctly.

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?

For a two-parameter, no-output-schema, no-annotation mutation tool, the description covers the essential contract, but leaves open whether the state is durable, whether omitting `until` implies indefinite `away`, and how conflicts with other agents' view of presence resolve. Adequate but with visible gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning to the bare enum values by explaining the effect of each state (notification holding, urgent-only routing). The `until` semantics are already in the schema, so no further credit there.

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 ("Set your OWN availability") and enumerates the exact accepted states with their meaning. The self-only clause ("never inferred, never set on your behalf") separates it from neighboring tools like team_status or team_style_set without requiring the agent to open another schema.

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?

The motivation sentence ("agents had no way to say they were away") makes the use case concrete, and the CLI twin `musterd availability` maps the concept for agents familiar with the CLI. It lacks an explicit "do not use this to read or set other members' status" pointer to a specific sibling, so it stops short of full routing 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