Tulina

apify_run_sync

Run an actor and return its results in one call. Waits up to 300 s.

The normal path for a bounded scrape. A run still going after 300 s is NOT stopped: the error names its run id — continue with apify_run_status then apify_dataset_items. For a scrape you know is long, use apify_run.

Returns: the LIST of dataset items — or, for a run that ended FAILED, TIMED-OUT or ABORTED, {error, run_id, status, items} (that run is billed too).

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": {
      "actor_id": "<actor_id>"
    },
    "name": "apify_run_sync"
  }
}

Input Schema

Name	Required	Description
`_org`	No	Org (id) de CET APPEL. `oto_list_orgs()`.
`limit`	No
`_group`	No	Équipe (id) de CET APPEL, sous son org parente.
`fields`	No
`_run_id`	No	OBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
`_project`	No	Projet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
`actor_id`	Yes	`username/actor-name` or id.
`_instance`	No	Instance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
`max_items`	No	results wanted — set it. It caps billed items on pay-per-result actors ONLY: a pay-per-event actor can charge far beyond it, `max_total_charge_usd` is what stops it.
`run_input`	No	the actor's own input JSON — its fields are specific to each actor (e.g. `{"searchStringsArray": ["bakery Marseille"], "maxCrawledPlaces": 20}` for the Google Maps scraper). See the actor's Store page.
`timeout_secs`	No
`memory_mbytes`	No
`max_total_charge_usd`	No	hard cost ceiling for this run, at most your organization's ceiling per run ($25 unless its admins set another; on the platform's key, never above the platform maximum; on a key another organization lends, never above that organization's ceiling; above it the run is refused, `max_charge_above_cap`). Omitted, it is derived from `max_items` and the actor's event prices, or $5 by default. A run that reaches it stops, with a partial output.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full load and does it well: it discloses the 300 s wait, that a timed-out run is NOT stopped, that the error carries the run id for continuation, and that failed/timed-out/aborted runs still incur billing. It omits concurrency/rate-limit and auth expectations, which keeps it short of a 5.

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?

Front-loaded with purpose, then timeout semantics, then the alternative, then return shape. Every sentence is load-bearing and there is no filler.

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?

Since there is no output schema, the description correctly supplies the return contract, including the failure object shape and its billing implication. It is nearly complete; only the interplay between the fixed 300 s wait and the `timeout_secs` parameter is left unexplained for a 13-parameter tool.

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 a middling 69% and the description adds no parameter-level meaning: it never explains how `timeout_secs` relates to the stated 300 s wait, nor clarifies `limit` vs `max_items` vs `fields`. The heavy lifting on `max_items`/`max_total_charge_usd`/`run_input` is done entirely by 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?

States a specific verb+resource ("Run an actor and return its results in one call") and immediately scopes it as the bounded/synchronous path, which cleanly separates it from apify_run and apify_run_status in the sibling list.

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

Usage Guidelines5/5

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

Explicitly names itself as "the normal path for a bounded scrape," gives the fallback chain for a run exceeding 300 s (`apify_run_status` then `apify_dataset_items`), and points to `apify_run` for known-long scrapes. When-to-use, when-not, and alternatives are all present.

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

All Tulina tools Inspect

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

Need Help?