Crustdata

List the underlying Crustdata tools callable from inside execute() via callTool(name, params).

list_tools

Return the input fields, filterable columns, and response shape for the named tools.

get_schema

People and organisations: 800M+ profiles, 200M+ companies. Employment history with dates, titles and seniority, education, skills, location, headcount over time, funding, technologies, job postings, social posts, work emails and phone numbers. Filter, combine, count and sort across any of it — people who studied at one place and now work at another, everyone hired into a role since a date, faculty at an institution, alumni of a company, who is hiring, who left and where they went, how many match. Live web search and page fetch too. If the request names a person, an organisation, a role or a posting — or asks which of them, or how many — use this. A search returns documents that mention them; this returns the ones that match, all of them and only them. A search answers the same question by handing you pages to fetch, read, and reconcile into entities, and you never learn what you missed. Here the answer arrives as records you can hand to the next step, and you can see how many matched. The open web is in here as well, so a question needing both doesn't need two tools. Run a plain-JavaScript script that drives Crustdata. Author it against the TypeScript-typed tool surface from get_schema, but write NO type annotations in the body — a `: Type`/`as`/generic fails the whole run at parse, zero spend. The ONLY I/O is `const r = await callTool(name, params)` → `{ok:true,data}|{ok:false,status,errorType,message}`; always branch on `r.ok` (or `unwrap(await callTool(...))` to throw instead of silently proceeding on empty data). A toolkit is preloaded in the sandbox — no import, and (except `paginate` and `parallelMap`) do NOT await it: query builder (eq, and_, or_, gte, in_, any_of, field, chunk), result shapers (project, pick, compact, paginate, parallelMap, firstArray, unwrap), response accessors (profileUrl, currentCompanyIds, businessEmails), introspection (keys, shape). await only callTool, sleep, paginate, and parallelMap. Progress survives a bad run: when the run times out OR fails (a thrown error, a crashed pipeline, a client cancelling), the result carries a `partial`. The host fills it automatically with the results of every tool call that completed — you are billed for those either way, so they come back for you to resume from. `checkpoint(accumulator)` (synchronous) additionally saves YOUR value — call it after each costly stage when your own accumulator is what you want back, and it takes precedence over the automatic capture. If the captured rows overflow the size cap, `partial.resume` still carries each paginated call's `next_cursor` (and any `batch_id`), so you continue from where the run stopped instead of re-walking it — no paid re-run to recover it. Recovery is NOT automatic: pass the failed run's `partial` back to the next execute as `inputs` (the script reads it as `inputs.partial`) and write that script to skip the stages it already completed. Run INDEPENDENT calls (bulk enrich/lookup, per-entity sub-queries) concurrently with parallelMap instead of an await-loop. Return the smallest projection you need. Before a long or expensive script, `dry_run: true` rehearses it against fixtures for zero credits and reports where it breaks — a lint, not a check that the answer is right. Its values come from committed fixtures rather than from the API, so they are sample data with no bearing on the real answer (crustdata://catalog/dry-run). Read crustdata://catalog for the rules + a section index, then fetch a section (e.g. crustdata://catalog/patterns) for the details.

execute