Skip to main content
Glama

Approve the call

approve_call
DestructiveIdempotent

Start the prepared call using next. direct_call reaches only the owner’s verified account number, without ownerConfirmation or a page: normally ask if they are ready; explicit instructions, an agreed routine or urgency may justify starting now. Ordinary calls need fresh ownerConfirmation to the recap. Set extraMinutes within the allowed limit. For a later time the owner chose, add notBeforeUtc. Personal calls get a Start link. Retry lost replies unchanged. get_guide final_review explains.

Input Schema

NameRequiredDescriptionDefault
taskIdYesThe task’s id: task.taskId in any reply about it, or from prepare_task, list_tasks or find_task.
versionYesThe task’s version from the latest reply (task.version or next[].arguments), exactly as given.
extraMinutesNoMinutes the call may run past its included time if it runs over, charged only if used; 0 ends it there. Omitted: what the owner pre-approved, as in next. More than that needs their yes to that time.
notBeforeUtcNoWhen the owner asked for a later time: a UTC time in exactly this form: 2026-10-01T13:00:00.000Z, up to 7 days ahead and before the request’s deadline. Leave it out to call as soon as allowed.
ownerConfirmationNoThe owner’s own words of approval.

Output Schema

NameRequiredDescriptionDefault
hintNoOptional guidance for helping the owner at this step. Advisory; never a permission grant. Wording may change.
nextYesCalls to make next.
statusYespending: check again later; requires_user_action: the owner must act; error: refused.
meaningYesWhat happened, for you.
sayToOwnerYesA line for the owner.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / notBeforeUtc
      Added value: +{
      +  "description": "When the owner asked for a later time: a UTC time in exactly this form: 2026-10-01T13:00:00.000Z, up to 7 days ahead and before the request’s deadline. Leave it out to call as soon as allowed.",
      +  "maxLength": 24,
      +  "pattern": "^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}\\.\\d{3}Z$",
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "taskId",
      -  "version",
      -  "ownerConfirmation"
      -]New value: +[
      +  "taskId",
      +  "version"
      +]
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare write, destructive, open-world and idempotent traits; the description adds operational behavior such as fresh ownerConfirmation for ordinary calls, direct_call's exemption, extraMinutes charging only if used, later-time scheduling, and 'Retry lost replies unchanged' aligning with idempotency. It does not spell out the practical consequences of a destructive real-world call, so 4 rather than 5.

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 purpose is front-loaded and the description packs many operational rules into a short space with little filler. However, the telegraphic style and undefined shorthand ('using next', 'recap') reduce structural clarity.

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 annotations covering safety flags, a full input schema, and an output schema, the description supplies the needed usage, confirmation, scheduling, and retry context. It is complete enough to call correctly, though it could clarify internal terms and destructive consequences.

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% and the schema already documents taskId, version, extraMinutes, notBeforeUtc, and ownerConfirmation in detail. The description adds only light reinforcement ('Set extraMinutes within the allowed limit', 'add notBeforeUtc' for later times) and a usage-level confirmation requirement. 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?

The opening 'Start the prepared call using next' names a specific verb and resource, and the text distinguishes it from direct_call, which reaches only the owner’s verified number without ownerConfirmation. However, it relies on internal shorthand ('next', 'recap') and does not distinguish against sibling call-handling tools such as start_welcome_call or retry_call.

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 concrete conditions: normally ask if ready, start now only with explicit instructions, an agreed routine or urgency, and ordinary calls require fresh ownerConfirmation. It also names direct_call as an alternative with different confirmation behavior. The guidance is dense and partly implicit, so it is not a perfect 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.

Resources