Skip to main content
Glama

Update scheduled job

update_job
Destructive

Replace a job's spec, or pause it with enabled=false. Job spec: {"series": name, "cron": "m h dom mon dow" (UTC, at most every 30 min), "request": {"url", "method"?: "GET"|"POST", "headers"?: {}, "body"?: obj|str, "pages"?: {"param": "page", "start"?: 0, "max"?: 1-10} (json with items: bump a query parameter until an empty items array) | {"cursor": "paging.next.after", "into": "after", "max"?: 1-10} (copy that JSON path from each response into the JSON body; stop when it is missing. A cursor that remains after max pages is an error, so a sum is never a partial total. HubSpot CRM search uses this. A json aggregate with no request.pages fails when the body still has another page, paging.next.after, has_more true, links.next, pageInfo.hasNextPage or another next cursor, instead of saving a partial total. Set pages. A response with no next marker is complete.)}, "extract": {"format": "json", "items"?: "path.to.array", "date"?: "field", "value": "field", "value_type"?: "number"|"text", "aggregate"?: "count"|"sum"|"mean"|"min"|"max" (records per date, e.g. hourly prices to a daily mean; needs items; all but count need value), "period"?: "D"|"M"|"Q", "where"?: [{"field": "path", "equals"|"not_equals": value}] (up to 5, with aggregate). Omit "date" with aggregate to snapshot every matching record as one point on the fetch's half hour. String numbers (HubSpot properties.amount) are summed.} | {"format": "json_columns", "dates": "path.to.array", "values": "path.to.array", "value_type"?} (two parallel arrays, e.g. Yahoo chart: timestamp + close) | {"format": "csv", "date"?: "COLUMN", "value": "COLUMN", "delimiter"?, "value_type"?} (omit date to stamp every row with the fetch's half hour; one value per half hour, so the last row wins. That does not sum the rows the way a JSON aggregate that omits date does. A history needs a Date column. Make a copy https://docs.google.com/spreadsheets/d/1Ty5X3LkY2unxTNGbkq36qDzuuYxQMsuywaTNyzL_pac/copy. Public CSV https://docs.google.com/spreadsheets/d/1Ty5X3LkY2unxTNGbkq36qDzuuYxQMsuywaTNyzL_pac/export?format=csv&gid=1746689811. Downloads /templates/google-sheets.csv and /templates/google-sheets.xlsx.) | {"format": "jsonstat2"} (SSB/Eurostat; filter the query to a single series), "transform"?: [{"op": "pct_change"|"diff"|"rolling_mean"|"rolling_sum"|"rolling_min"|"rolling_max"|"shift", "n": int} | {"op": "scale", "factor": num}], "keep"?: "all"|"last"}. "value_type": "text" stores labels (no transforms; see Data policy). Dates like 2026-09-30, 2026M08, 2026Q2/2026K2, 2026 or unix time are normalised to ISO period-end dates; date-times (2026-10-05T14:00+02:00) count on the day as written. A single JSON value with no timestamp (omit "date", or a date path the body doesn't have) is dated with the fetch's half hour: that is valid for a snapshot such as a price. A date that is present but not a date is an error. Do not invent a timestamp field. URLs and string bodies may use {today}, {yesterday}, {tomorrow}, {year}, {month}, {day} (UTC, filled in on every run) for sources that put the date in the URL. Private APIs: the URL, header values and string body may use {{secret:NAME}} for a secret the workspace owner stored (list_secrets shows the names and the one host each may be sent to); the value is filled in at fetch time and never shown, e.g. "headers": {"Authorization": "Bearer {{secret:STRIPE_KEY}}"}. A stored secret may be sent on GET, on a POST whose body is a GraphQL query, or on POST https://api.hubapi.com/crm/v3/objects/{deals,contacts,companies}/search only (HubSpot's read-only CRM search, JSON body; https://developers.hubspot.com/docs/api-reference/legacy/crm/search-the-crm). No other POST may carry a secret, and the secret is still sent only to the host it was saved for. If a needed secret is missing, ask the user to add it at /account under Data sources.

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": {
      "job_id": "<job_id>",
      "spec": "<spec>"
    },
    "name": "update_job"
  }
}

Input Schema

NameRequiredDescriptionDefault
specYesjob spec
job_idYesid
enabledNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the annotations, the description discloses that replacing a spec is a full destructive replacement, that enabled=false pauses the job, and it details validation constraints, error conditions, date normalization, cursor handling, and secret injection rules. This is unusually rich behavioral context for a mutation tool whose annotations already mark it destructive and non-idempotent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the description becomes a dense wall of parenthetical edge cases, repeated cursor warnings, and external links. Much of the detail is relevant for a complex nested spec, yet the structure is difficult to scan and some sentences could be tightened or moved into schema descriptions.

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?

Given the complex nested spec and the absence of an output schema, the description is largely complete: it covers the job spec grammar, transforms, date handling, pagination, error cases, and secrets. It still does not explain the job_id parameter or what update_job returns, which leaves minor gaps for a mutation tool.

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?

The schema only describes spec as 'job spec' and job_id as 'id', but the description extensively defines the spec's cron, request, extract, transform, keep, cursor, pagination, date, and secret semantics. It also explains enabled=false for pausing, though it does not explicitly describe the required job_id parameter beyond the phrase 'a job's spec'.

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 opens with a specific verb and resource: replace a job's spec, or pause it with enabled=false. It clearly distinguishes an update/pause operation from sibling tools such as create_job, delete_job, run_job_now, and test_job.

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?

The description implies when to use the tool by stating it replaces a job's spec or pauses it, but it does not explicitly compare against create_job, delete_job, run_job_now, or test_job. The usage context is clear enough to infer, but alternatives and exclusions are not named.

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.