Skip to main content
Glama

Prepare an audit schedule

prepare_schedule

Preview a recurring audit schedule for a prompt set. Pass market_ids (from the project context; null is the default market) to run one audit per market. Each recorded answer spends one prompt run. Nothing changes until the user agrees and you call confirm_change.

Input Schema

NameRequiredDescriptionDefault
cadenceYesHow often the audit runs.
enginesYesThe AI engines to ask; at least one.
timezoneNoAn IANA timezone such as Europe/London; omit for the default.
market_idsNoMarket ids from get_project_business_context; null is the default market. Omit for the default market only.
project_idYesA project id that list_projects returned.
next_run_atNoWhen the first run starts; omit to start right away.
repetitionsNoHow many times each prompt is asked per engine; omit for the project default.
prompt_set_idNoA prompt set id from read_prompt_portfolio; omit when the project has only one prompt set.
interval_minutesNoMinutes between runs; only for cadence every_n_minutes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changed
    • addedInput schema / properties / cadence / description
      Added value: +"How often the audit runs."
    • addedInput schema / properties / engines / description
      Added value: +"The AI engines to ask; at least one."
    • addedInput schema / properties / interval_minutes / description
      Added value: +"Minutes between runs; only for cadence every_n_minutes."
    • addedInput schema / properties / market_ids / description
      Added value: +"Market ids from get_project_business_context; null is the default market. Omit for the default market only."
    • addedInput schema / properties / next_run_at / description
      Added value: +"When the first run starts; omit to start right away."
    • addedInput schema / properties / project_id / description
      Added value: +"A project id that list_projects returned."
    • addedInput schema / properties / prompt_set_id / description
      Added value: +"A prompt set id from read_prompt_portfolio; omit when the project has only one prompt set."
    • addedInput schema / properties / repetitions / description
      Added value: +"How many times each prompt is asked per engine; omit for the project default."
    • addedInput schema / properties / timezone / description
      Added value: +"An IANA timezone such as Europe/London; omit for the default."
  2. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds genuinely useful behavior beyond them: this call is a preview that changes nothing, it commits only after an explicit confirm_change, and it consumes one prompt run per recorded answer — real cost information an agent needs before invoking.

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?

Three short sentences, front-loaded with purpose, then the market_ids behavior, then the cost and commit gate. Every sentence carries distinct information with 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 9-parameter scheduling tool with full schema coverage and annotations, the description supplies the missing pieces an agent needs: preview semantics, the confirm_change commit path, and prompt-run cost. No output schema exists, so return-format detail is not required; only an explicit contrast with prepare_launch_audit is absent.

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 coverage is 100%, so baseline is 3. The description goes slightly further by explaining the effect of market_ids (one audit per market) and that null/omitted means the default market, which is semantic behavior rather than a restatement of the schema types.

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?

States a specific verb (preview/prepare) and resource (recurring audit schedule for a prompt set), and the 'Preview' framing plus the confirm_change reference distinguishes it from the raw mutation siblings. It does not explicitly contrast with the closest sibling prepare_launch_audit (one-time vs recurring), so sibling differentiation is only implicit.

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 clear operating context: create the schedule here, nothing takes effect until the user agrees and confirm_change is called, and market_ids drives one audit per market. It stops short of an explicit when-not rule (e.g. one-time launches vs recurring schedules), but the workflow step is unambiguous.

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