Skip to main content
Glama

Invite someone to the household

invite_to_household

Create a one-time link that lets another ask.recipes user join the user's household, for "add my wife to my household", "share my pantry with Sam", "connect my partner's account". The first call creates the household, so pass my_name (what the family calls the user) and optionally household_name. The person opens the link, enters their name and email, confirms a 6-digit code and is in; an account is created for them when they have none. On joining, their pantry merges into the shared one and their cooking diary becomes the household's. Give the user the link as is to forward; it works once and expires in a day. Up to 6 members, and an account can be in one household at a time.

Input Schema

NameRequiredDescriptionDefault
my_nameNowhat the household calls the user, e.g. 'Dad' or 'Ana'; required the first time, when the household is created, and shown to the person invited
household_nameNoa name for the household when creating it, e.g. 'Casa Silva' or 'Home'; defaults to Home

Output Schema

NameRequiredDescriptionDefault
noteYes
join_urlYesone-time link the user sends to the person joining; works once and expires in a day
householdYes
expires_in_hoursYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing the one-time link semantics, 24-hour expiry, 6-member cap, one-household-per-account limit, automatic account creation for invitees, and the side effects of joining (pantry merge, cooking diary becoming the household's). These are exactly the behavioral traits an agent needs before invoking a non-idempotent mutation.

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?

Front-loaded with the purpose, then constraints and flow in a logical order. The three quoted example utterances are somewhat redundant and could be trimmed, but no sentence is wasted overall.

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?

An output schema exists so return values need not be explained. The description covers all the operational constraints an agent needs: invite flow, expiry, member cap, side effects, and account creation, leaving no significant gap.

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 schema already documents both parameters. The description restates that my_name is what the family calls the user and that it is required when the household is created, adding only marginal meaning beyond the schema's own descriptions.

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: 'Create a one-time link that lets another ask.recipes user join the user's household.' It is clearly distinguishable from siblings like get_household, update_household, and remove_from_household, and the example utterances reinforce the intended use.

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?

Provides concrete when-to-use signals through example utterances and explains the first-call-creates-household behavior, including when my_name is needed. It does not explicitly exclude alternatives (e.g., update_household for renaming, get_household for viewing), so it falls short of a 5.

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.