Skip to main content
Glama
Sign In

tlly

by dev.tlly
OverviewDiscussionsAdmin

Create scheduled job

create_job
Destructive

Schedule a fetch job. It runs once immediately and the result is returned. 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": {
      "spec": "<spec>"
    },
    "name": "create_job"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNooptional label
specYesjob spec

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true, openWorldHint=true and idempotentHint=false, so the safety profile is covered; the description nonetheless adds real substance beyond them: the immediate first run, the 30-minute cron floor, UTC handling, secret-injection rules and host scoping, and several explicit error conditions (leftover cursor after max pages, json aggregate without pages, a present-but-invalid date). It does not say what the tool returns or whether creating a job is reversible.

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

Conciseness2/5

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

While front-loaded with the key sentence, the body is a single unbroken block of dense prose with nested parentheticals and mid-sentence asides ("A cursor that remains after max pages is an error, so a sum is never a partial total"). Extraneous template URLs for Google Sheets and HubSpot docs dilute the specification rather than structuring it.

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 free-form nested spec tool with no output schema, the definition covers the grammar, date semantics, transforms, secret handling and failure modes in unusual depth. Gaps remain around the return value of "the result", job identity/name usage, and how the created job relates to run_job_now or update_job.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema declares `spec` as an opaque object with the description "job spec", so the description carries the full burden and does it thoroughly: it enumerates series/cron/request/extract/transform/keep, each extract format's required fields, cursor and pagination semantics, value_type behavior, and date normalization. None of this is derivable from the input schema.

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 sentence gives a specific verb and resource ("Schedule a fetch job") plus an important behavioral fact (runs once immediately, result returned). However, it never distinguishes this from siblings such as test_job, import_once, run_job_now or update_job, which an agent could plausibly confuse with creating a scheduled fetch.

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

Usage Guidelines2/5

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

There is no when-to-use/when-not guidance relative to alternatives: nothing says to call test_job first to validate the spec, or update_job to modify an existing job. The only prerequisite note is the secret-related instruction to ask the user to add a missing secret at /account, which is useful but narrow.

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

All tlly 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