openactors
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | Port on which the HTTP server listens. | 8080 |
| PROXY_URL | No | Full proxy URL in the form http://user:pass@host:port. When set, all crawl requests are routed through this proxy. | |
| AUTH_TOKEN | No | Authentication token for the HTTP server. Required when exposing the port; optional for local stdio use. Sent as a Bearer token in requests. | |
| PROXY_MODE | No | Proxy mode, e.g. 'gateway'. | |
| PROXY_USER | No | Account username for the residential proxy provider. | |
| WEBHOOK_URL | No | URL to receive Apify-style webhook events. If set, overrides webhooks.json. | |
| PROXY_PRESET | No | Proxy preset: apify, iproyal, oxylabs, dataimpulse, or evomi. | |
| PROXY_COUNTRY | No | Country code for proxy session targeting, e.g. 'US'. | |
| OAUTH_PASSWORD | No | Password required for the OAuth consent page when connecting via a tunnel. | |
| PROXY_PASSWORD | No | Account password for the residential proxy provider. | |
| PROXY_SESSION_TTL_SECS | No | Session TTL in seconds for the proxy session. | 1800 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search-actorsA | Search available Actors (scrapers and data collectors) by keyword. Returns each Actor's id, title and description. Start here when you need to extract data from the web. Pass an empty search to list everything available. |
| fetch-actor-detailsA | Get the full JSON Schema for an Actor's input, plus its description. Call this before call-actor so you know which fields are required and how they are named. |
| call-actorA | Run an Actor and return its results. The shape of |
| get-actor-runA | Get the status, item count and dataset id of a previous run. Use this after call-actor to check whether a run succeeded, failed, or was aborted. |
| get-actor-run-listA | List recent Actor runs in this server session, newest first. |
| get-actor-logA | Read the log of a run. This is where an Actor reports per-board or per-page failures that did not fail the run as a whole — check it when a run succeeded but returned fewer items than you expected. |
| abort-actor-runA | Stop a run that is still in progress. Items already collected are kept. |
| get-dataset-itemsA | Page through the results of a previous Actor run. Use the datasetId returned by call-actor. Use |
| get-datasetA | Get the item count of a dataset without reading the items themselves. |
| get-dataset-schemaA | Infer the shape of a dataset from a sample of its items. Use this to learn which fields exist before requesting them via |
| get-key-value-store-recordA | Read a single record from a key-value store by key. |
| create-actor-taskB | Save a named Actor configuration so a search worth repeating gets an id instead of a body of JSON to retype. Re-using an existing id updates it. |
| get-actor-taskA | List saved tasks, or fetch one by id. |
| delete-actor-taskA | Remove a saved task. The runs and datasets it produced are kept. |
| run-actor-taskB | Run a saved task. Any fields given in |
| resurrect-actor-runA | Re-run a finished run with the same Actor and input, optionally with a longer timeout — the usual reason a run needs resurrecting. Creates a new run, so the original's results and diagnosis stay intact. |
| create-scheduleB | Run an Actor or a saved task on a cron schedule, executed by the server itself. Give either |
| get-schedulesA | List schedules with their next and last run times. |
| delete-scheduleA | Remove a schedule. Runs it already produced are kept. |
| clean-up-storageA | Delete datasets and stores older than |
| mark-jobA | Record that you have applied to a role or dismissed it. Marked roles stop appearing in future digests, which is what turns the digest from a feed into a working list. Accepts several URLs at once. |
| get-marked-jobsA | List roles recorded as applied or ignored, newest first. |
| get-follow-upsA | Lists roles applied to that have gone quiet, longest wait first. Anything that has had a response — including a rejection — is excluded, and an application already chased inside the window is not chased again. |
| record-responseA | Note that an employer replied, rejected, invited you to interview or made an offer. Stops that application appearing in follow-ups. |
| record-follow-upA | Records that you followed up, so the same silence is not flagged again immediately. |
| unmark-jobA | Forget that a role was applied to or ignored, so it can appear again. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 26 tools
Tools are grouped into clear clusters—actors, runs, tasks, datasets, schedules, and job tracking—and each tool targets a distinct resource and action. A few pairs like call-actor vs run-actor-task and mark-job vs record-response are somewhat close, but their descriptions clearly separate them.
Most tools follow a lowercase hyphenated verb-noun pattern, which is readable and mostly predictable. There are minor inconsistencies such as fetch vs get, call vs run, clean-up vs delete, and list naming varies (get-actor-run-list vs get-actor-task vs get-schedules).
At 26 tools, the set is over the 25-tool threshold and feels heavy for an agent to navigate. The actor, dataset, schedule, and job-tracking concerns are broad enough that the server may be trying to cover too much in one surface.
The set covers actor discovery, execution, run inspection, saved tasks, datasets, schedules, storage access, and job follow-up workflows with no obvious dead ends. Minor gaps exist: key-value store access is read-only and there is no individual dataset deletion, though clean-up-storage partially covers cleanup.