Skip to main content
Glama

Create scheduled review

create_scheduled_review

Create a recurring public-page review with the same plan limits and cadence as the dashboard. Enables future scans and review emails. A lost response can be recovered by listing schedules; the same project, page and scan type cannot have duplicate schedules.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "projectId": "<projectId>",
      "url": "<url>",
      "scanType": "<scanType>",
      "cadence": "<cadence>"
    },
    "name": "create_scheduled_review"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYes
cadenceYes
scanTypeYes
projectIdYes
confirmLoginPageNoTrue only when the user explicitly wants to review the sign-in page itself

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations only declare it is a non-destructive, non-idempotent, open-world write. The description adds real behavioral context: plan-limit enforcement, cadence parity with the dashboard, a uniqueness constraint on project/page/scanType, and a recovery path via listing schedules when no output schema exists.

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?

Three tight sentences, front-loaded with purpose, then side effects, then failure/recovery handling. Nothing wasted; only the missing parameter guidance keeps it from a 5.

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 5-parameter mutation with no output schema and only sparse annotations, the description covers side effects (future scans/emails), plan limits, the duplicate failure mode, and recovery. Auth/permission needs and the returned object identity are the remaining gaps.

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 only 20% (only confirmLoginPage is documented), so the description must carry weight. It hints that project, page and scan type jointly form a uniqueness key, but gives no meaning for url format beyond the schema, no cadence/scanType value semantics, and never mentions confirmLoginPage.

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+resource ('Create a recurring public-page review') and scopes it to recurring scans tied to plan limits and cadence. That reliably separates it from create_client_review and run_scheduled_review, though no sibling is named outright.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Enables future scans and review emails' implies this is the tool for scheduling rather than running an immediate scan, and the duplicate constraint tells the agent when a create will fail. But it never explicitly names alternatives like run_scheduled_review or create_client_review or states when not to schedule.

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.