Skip to main content
Glama

unavailability_notice_email

Draft a heads-up email to clients about your upcoming absence — vacation, conference, or personal — with exact dates and pre-departure deliverables, so clients aren't surprised when you go offline.

Instructions

Write a proactive heads-up email to an active client before you go away — annual leave, a personal absence, or a conference/training. Sends this BEFORE you leave so the client isn't surprised when you go quiet. Three routes: vacation (default — fully offline; states the exact dates, what you'll complete before you go, and when you'll respond on return; gives the client confidence that active work is handled), conference_or_training (professional development; acknowledges you may check email intermittently; warmer tone since you're still reachable in genuine emergencies), personal (minimal detail — just the dates and return; no explanation required). Distinct from project_pause_email (formal indefinite pause, often for non-payment), availability_announcement_email (announcing new slots for future work), and project_delay_notification_email (your own delay mid-project). Does not count against your monthly draft limit. Required: client_name, return_date (when you'll be back — e.g. 'Monday 7 July', 'next Thursday'). Optional: project_name, from_date (first day away — e.g. 'Friday', '27 June'; omit if sending on the day of departure), pre_absence_deliverable (what you'll complete before you leave — e.g. 'the first-draft wireframes', 'the revised copy'), cover_contact (name + email of someone handling genuine emergencies — omit if you have no cover), route ('vacation' | 'conference_or_training' | 'personal' — default vacation), your_name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
client_nameYesClient first name
return_dateYesWhen you'll be back and responding to emails — e.g. 'Monday 7 July', 'next Thursday', '14 July'. Give a specific date so the client has a concrete expectation.
project_nameNoOptional: project name — e.g. 'the Hartley website', 'your brand refresh'. Makes the email specific rather than generic.
from_dateNoOptional: first day away — e.g. 'Friday', '27 June', 'tomorrow'. Omit if sending on the day of departure.
pre_absence_deliverableNoOptional: what you'll complete and send before you leave — e.g. 'the first-draft wireframes', 'the revised copy deck', 'the updated timeline'. Reassures the client that active work is handled.
cover_contactNoOptional: name and contact for genuine emergencies — e.g. 'Sarah (sarah@agency.com)'. Omit if you have no cover. Do not list a cover contact unless you have one — a named contact who doesn't respond is worse than no contact.
routeNovacation (default) — annual leave, fully offline; conference_or_training — professional development, may check email intermittently; personal — minimal detail, just the dates.
your_nameNoOptional: your name for the sign-off
Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses that the email is sent before departure, covers different routes with appropriate tones, and notes that it does not count against the monthly draft limit. It could mention more about sending behavior or potential side effects, but overall it provides key behavioral context.

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?

The description is well-structured, front-loading the purpose and then detailing routes and parameters. While it is somewhat verbose, every sentence adds value. It is efficient for the complexity of the tool without being padded.

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 8 parameters, 2 required, and no output schema, the description comprehensively covers all parameters with examples and context. It explains the three routes, contrasts with siblings, and notes the no-draft-limit feature. It is fully complete for an AI agent to correctly invoke the tool.

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 description coverage is 100%, so baseline is 3. The description adds significant meaning beyond the schema: it explains the three routes in detail, provides examples for parameters like from_date and pre_absence_deliverable, and gives strong guidance like 'do not list a cover contact unless you have one'. This greatly aids proper parameter usage.

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 clearly states it writes a proactive heads-up email before absence. It distinguishes three specific routes (vacation, conference_or_training, personal) and explicitly contrasts with sibling tools (project_pause_email, availability_announcement_email, project_delay_notification_email), making the purpose highly specific.

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?

The description explicitly explains when to use (before going away) and provides detailed guidance on each of the three routes. It also distinguishes from sibling tools, telling what this tool is for and what it is not for. Required vs optional parameters are clearly stated.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jabbawocky/proposalcraft'

If you have feedback or need assistance with the MCP directory API, please join our Discord server