Skip to main content
Glama
Sign In

AnalyticsProof

by com.analyticsproof
OverviewDiscussionsAdmin

List scan schedules

list_schedules
Read-onlyIdempotent

List scan schedules (permission: read)

Scan schedules of the key's project. Filter with ?targetId=. A target of another project yields an empty list. During a new test's first 48 h, nextRunAt can precede the cron: priming pulls the first runs forward. lastRunAt is when the last scan of this test type was committed, scheduled or manual (a "Scan again" moves it too).

list_scans lists the scans that ran.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_schedules"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoPage size, 1–100.
cursorNoThe previous page's `nextCursor` (opaque). A malformed cursor is 400 on path cursor (issue code invalid_cursor).
targetIdNoReturn only the schedules of this scan target.
projectIdNoRequired with an organization key; must be the key's project with a project key. Missing (organization key) or not a UUID: 400 invalid_request on path projectId; a project outside the key's reach: 404.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already carry readOnly/idempotent/non-destructive, so the bar is lower; the description still adds real behavior: the read permission requirement, that a targetId from another project returns an empty list rather than an error, that nextRunAt can precede the cron during the first 48 h of a new test, and that lastRunAt reflects scheduled or manual commits. Missing are ordering of results and what a page looks like, but the surprising edge cases are disclosed.

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?

Scope and permission lead, then filtering and edge cases, then the sibling disambiguation last. Every sentence carries non-obvious information; the dense nextRunAt/lastRunAt clarification is warranted because those fields behave unintuitively.

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 four-parameter, read-only list tool with full schema coverage and annotations, the description supplies the field semantics an agent needs to interpret results (nextRunAt, lastRunAt) plus the permission and cross-project behavior. Result ordering and pagination dynamics are the remaining gaps, which the schema largely covers.

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 still adds meaning beyond the schema for targetId by stating that a target outside the project yields an empty list, which the schema's "return only the schedules of this scan target" does not imply. limit, cursor and projectId are left entirely to 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 uses a specific verb and resource ("List scan schedules") and scopes it to "the key's project," then explicitly contrasts with the sibling: "list_scans lists the scans that ran." An agent can distinguish this from list_scans and get_scan without opening any schema.

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 names the intended use (listing schedules of the key's project), states that filtering is done with targetId, and clarifies the boundary against the closest alternative, list_scans. It does not cover when to prefer trigger_scan or rerun_target_scan, but no exclusions are actively misleading.

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

All AnalyticsProof toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources