Skip to main content
Glama
Sign In

tlly

by dev.tlly
OverviewDiscussionsAdmin

Import data once

import_once
Destructive

Fetch a job spec once and save the result, without scheduling it or using a job slot ("cron" is optional and ignored). Use for one-off dashboards whose data doesn't need to update; points count toward the data quota. 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": "import_once"
  }
}

Input Schema

NameRequiredDescriptionDefault
specYesjob spec

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior3/5

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

The description adds substantial behavior beyond the annotations: points count toward the data quota, "cron" is accepted but ignored, secrets are resolved at fetch time and restricted to specific hosts/methods, and cursor pagination that exceeds max pages errors instead of saving a partial total. These are genuine operational disclosures that the destructiveHint/openWorldHint annotations do not convey, so despite the density this is well above the minimum for a mutating tool.

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?

It is front-loaded with purpose before spec detail, and nearly every clause carries information. However, it is a single wall of nested parentheses and quoted keys, with awkward run-ons (the pages/next-marker passage repeats itself) and a Google Sheets template detour that interrupts the extract documentation.

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 one-parameter tool with a nested free-form object and no output schema, the description covers spec construction, date normalization, secret resolution, and failure modes thoroughly. It is weaker on what comes back after saving (no series id/identifier, no mention of how to read the data afterward via get_series), which an agent needs to chain the call.

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 is a bare {"spec": object} with the placeholder label "job spec", so the description carries essentially all the meaning: it defines series, cron, request (url/method/headers/body/pages), extract formats (json, json_columns, csv, jsonstat2), aggregate and where clauses, transforms, and keep. It also states edge-case rules (string numbers summed, text values skip transforms, missing date path stamps the fetch half hour), which is far more than the schema offers.

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 first sentence gives a specific verb and resource ("Fetch a job spec once and save the result") and immediately scopes it against scheduled jobs ("without scheduling it or using a job slot"). It distinguishes the tool from create_job/run_job_now conceptually, though it never names those siblings, so routing still requires inference.

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?

"Use for one-off dashboards whose data doesn't need to update" gives a clear positive condition, and the parenthetical about cron supplies an implicit exclusion. There is no explicit when-not or named alternative (e.g., create_job for recurring fetches), which keeps it below a 5.

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