Skip to main content
Glama

Add closed days

add_closure

Close a branch (or, with no branch_id, the whole business) from start_date to end_date (one day if no end). The reason shows to families (e.g. Christmas break). No lessons happen there on those days.

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": {
      "start_date": "<start_date>",
      "reason": "<reason>"
    },
    "name": "add_closure"
  }
}

Input Schema

NameRequiredDescriptionDefault
reasonYesShown to families, up to 120 characters.
end_dateNoLast closed day, YYYY-MM-DD, in the business's own time zone.
branch_idNoThe branch; leave out for the whole business (needs every branch).
start_dateYesFirst closed day, YYYY-MM-DD, in the business's own time zone.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

The description adds useful behavioral context beyond the annotations: the reason is shown to families, the closure prevents lessons, and omitting end_date creates a one-day closure. It does not discuss permissions or conflict handling, but annotations already establish this is a non-destructive write operation.

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?

Three short sentences front-load the operation and scope, then add the family-visible reason and lesson impact. There is no wasted text.

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?

For a four-parameter mutation with full schema coverage and no output schema, the description covers the key behavioral effects an agent needs: scope, date behavior, visibility of the reason, and lesson impact.

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 the default behavior that end_date omitted means one day. It also reinforces the branch_id scope and the family-visible reason, though most parameter details are already present in the schema.

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 action and resource: closing a branch or the whole business over a date range. It clearly distinguishes the scope via branch_id and explains the effect that no lessons happen on those days.

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 gives clear context for when to use the tool: to close a branch or whole business from start_date to end_date. It does not explicitly name alternatives like remove_closure or list_closures, but the intended usage is unambiguous.

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.

Resources