Skip to main content
Glama

mark_session_no_show

Mark a booked 1:1 session as a no-show (may count against the client's session pack). (confirm-gated: previews until confirm: true)

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": {
      "input": "<input>"
    },
    "name": "mark_session_no_show"
  }
}

Input Schema

NameRequiredDescriptionDefault
inputYes
confirmNoMust be true to actually execute. If false/omitted, returns a preview only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations only say readOnlyHint=false; the description adds real value by warning of the downstream effect ("may count against the client's session pack") and by disclosing the confirm-gated preview behavior. It doesn't say whether the change is reversible or what happens if the session is already completed.

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?

Two tight clauses with the core action first and the side effect plus confirm gate appended. Dense and front-loaded, though the stacked parentheticals read a bit awkwardly.

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 a confirm-gated mutation with no output schema, the description covers the action, the side effect, and the preview requirement. Missing only edge-case behavior (idempotency, already-completed sessions) and any mention of required permissions.

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 50%, and the description only clarifies the confirm parameter's gating semantics (already documented in the schema). Neither sessionId nor the optional reason field is given any meaning, format, or source in the description.

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 and resource ("Mark a booked 1:1 session as a no-show") and names the resulting state, which distinguishes it from mark_session_done or cancel_session without naming them. It stops just short of explicitly contrasting with those siblings.

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

Usage Guidelines3/5

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

The no-show condition implies when to use it (client failed to attend), and the confirm-gating note tells the agent how to execute. However, it never names alternatives like mark_session_done, cancel_session, or reschedule_session, nor states when this is the wrong choice.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.