Skip to main content
Glama
Sign In

withHuman

by ai.withhuman
OverviewDiscussionsAdmin

Create escalation path

create_escalation_path

Create an escalation path with its first revision and activate it (unless activate is false). A path says who reviews a request the pipeline hands to a person: level nodes page targets (user targets by membership id, team targets by team id) and wait escalate_after before the next level; if_else nodes branch on urgency, working hours or the request itself; defer nodes hold the request until working hours. Call read_reference (escalation_paths) first. The key is permanent: pipelines name it, and it stays taken even after archiving.

Input Schema

NameRequiredDescriptionDefault
nameYesDisplay name people see, for example Payments review.
nodesYesThe path's nodes in order: level nodes name targets and how long to wait (escalate_after) before the next level, if_else nodes branch on conditions, defer nodes wait for working hours. Every node needs a UUID id. See read_reference topic escalation_paths.
repeatNoWhat to do when every level has been paged and nobody answered: {times: 1..9, after: '15m'} walks the levels again.
activateNoActivate the new revision right away. Defaults to true. A path with no active revision cannot be named by an active pipeline.
path_keyYesStable key, lowercase letters, digits, dots, underscores or dashes (for example payments-review). It names the path from pipeline blocks and is never reused, even after archiving.
working_hoursNoNamed working-hours sets that defer nodes and working_hours conditions refer to by id: {id, timezone (IANA), intervals: [{weekdays: [mon, ...], start: '09:00', end: '17:30'}]}.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already indicate this is a non-readonly, non-idempotent creation tool. The description adds useful behavioral context: activation defaults to true, the path key is permanent and cannot be reused after archiving, and node types have distinct runtime semantics.

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 description is front-loaded with the core action and default behavior. It is dense but every sentence adds operational context, and there is no 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?

For a complex creation tool with nested node structures, the description covers creation, activation defaults, node types, prerequisites, and key permanence. It does not describe the return value, which is a minor gap given there is no output schema.

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 description coverage is 100%, so the schema already explains all six parameters. The description adds some cross-field and semantic context, especially around node behavior and permanent path keys, but most parameter meaning is redundantly covered by 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 verb and resource: creating an escalation path with its first revision and activating it. It clearly distinguishes creation from sibling operations like update_escalation_path or activate_escalation_path_revision.

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 an explicit prerequisite: call read_reference with the escalation_paths topic first. It also clarifies the default activation behavior. It does not explicitly compare when to use this versus update_escalation_path, so it falls short of full when/when-not guidance.

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

All withHuman toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources