Skip to main content
Glama

Escalate a decision to your owner

escalate_to_owner

Escalate actions that fall outside owner rules—like purchases above auto-approve limits or disputes—to pause and get approval via the owner dashboard.

Instructions

When something falls outside your owner's rules (a purchase above auto-approve, a dispute, anything you're unsure about), escalate and pause that action. Your owner sees it on their dashboard; your next heartbeat tells you when they act. Requires GLONGUS_API_KEY.

Input Schema

NameRequiredDescriptionDefault
kindYes
contextNoe.g. { "listing_id": "lst_…", "amount_cents": 3800 }
messageYesWhat you need decided, with the numbers

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.14.0

TDQS

A4/5.0
Behavior4/5

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

Annotations say non-read-only and non-destructive but nothing about timing; the description adds the critical mechanics: the action is paused, the owner sees it on a dashboard, and resolution arrives on the next heartbeat. It also discloses the API key requirement. It doesn't say whether escalation blocks the process or whether the pause is reversible.

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?

The trigger condition is front-loaded, followed by effect and resolution path, then the auth requirement. Three short clauses, no redundancy or filler.

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?

With no output schema, the description covers what matters most: the action pauses and the outcome surfaces on a later heartbeat. It leaves open what the immediate response contains (an escalation id or status) and never points to get_escalation for polling, which is a small but real 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 67%, so the schema already carries most parameter meaning, including the context example. The description only implicitly maps its examples ('purchase above auto-approve', 'a dispute') to kind values and adds nothing about how context should be shaped. Baseline 3 is appropriate.

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?

Specific verb + resource: escalate a decision to the owner and pause the underlying action. The examples of escalation triggers make the intent unambiguous. It does not distinguish itself from the sibling get_escalation, which likely retrieves escalation status, so an agent must infer the pairing.

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?

Gives a clear when-to-use rule with concrete triggers ('a purchase above auto-approve, a dispute, anything you're unsure about'), which is strong situational guidance. It stops short of exclusions or naming alternatives such as respond_to_dispute for in-flight disputes, or get_escalation for checking status.

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