Skip to main content
Glama

Run code against apinoa

execute
Read-only

Run TypeScript that calls apinoa APIs to fetch, fan out, filter, rank, count, and aggregate marketplace or social data in code, returning only compact results instead of raw API responses.

Instructions

Run TypeScript that calls the apinoa API, and get back only what it prints or returns. Use it for every data task, from one call to thousands: fan out over accounts or posts, follow pages, then filter, count, rank and average in the code, so raw API answers never fill the conversation.

The code is the body of an async function: use await, and return a small result (aggregate, slice, pick the fields you need). In scope:

  • apinoa..(params): one API call, returns the answer's data; throws ApinoaError (code, status) on a refusal. search_docs lists the parameters and the fields returned.

  • pages(op, params, { maxPages }): every item of a paged operation, following cursors (default 5 pages).

  • many(items, fn, { concurrency }): fn over every item, 8 at a time by default; a failed item comes back undefined.

  • store.save(name, value) / store.load(name) / store.list() / store.saveFile(name, base64): data kept on this machine between runs.

  • usage: { calls, units, budget } of this run. The code is type-checked before it runs: an operation, parameter or field that does not exist fails there, before anything is billed. Each call costs units (1 unit = $0.001, per search_docs); the run stops once budget_units are spent. Answers are cached for 10 minutes, so re-running after a fix costs nothing for calls already made. Only the API is reachable from the code.

Example: const page = await apinoa.tiktok.posts({ hashtag: "glassskin", limit: 50 }); const authors = [...new Set(page.items.map((p) => p.author.handle))].slice(0, 10); const recent = await many(authors, (u) => apinoa.tiktok.posts({ username: u, limit: 30 })); return authors.map((u, i) => { const views = (recent[i]?.items ?? []).map((p) => p.metrics?.views ?? 0).sort((a, b) => a - b); return { author: u, median: views[Math.floor(views.length / 2)] ?? null }; });

Operations (call search_docs with words or a platform for parameters, costs and the fields returned):

  • apinoa.aliexpress: search, browse, categories, imageSearch, product, shipping

  • apinoa.amazon: search, imageSearch, browse, categories, product

  • apinoa.instagram: profile, post, posts, comments, group, groups

  • apinoa.linkedin: profile, post, posts, comments, group, job, jobs

  • apinoa.reddit: profile, profiles, post, posts, comments, group, groups

  • apinoa.shopify: search, imageSearch, catalog, product, reviews

  • apinoa.threads: profile, post, posts, comments

  • apinoa.tiktok: profile, profiles, post, posts, comments, group, groups, media

  • apinoa.tiktokshop: search, browse, categories, catalog, product, reviews

  • apinoa.walmart: search, browse, categories, product, reviews

  • apinoa.x: profile, post, posts, group

  • apinoa.youtube: profile, profiles, post, posts, comments, groups

Input Schema

NameRequiredDescriptionDefault
codeYesTypeScript: the body of an async function. Return the result.
budget_unitsNoMost units this run may spend (default 500, at most 20000).
timeout_secondsNoStop the run after this long (default 300).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only say readOnly and openWorld, yet the description discloses the cost model (1 unit = $0.001), that the run halts at budget_units, 10-minute answer caching so retries after a fix are free, pre-execution type-checking before anything is billed, ApinoaError(code, status) on refusals, failed fan-out items returning undefined, and that only the API is reachable. That is unusually rich operational context an agent cannot get from structured fields.

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

Conciseness4/5

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

It is long, but the length is front-loaded value: the one-line purpose comes first, followed by scope, cost/error behavior, a worked example, and an operations index. The per-platform operation list is reference-heavy rather than instructional, which is the only thing that keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a code-execution sandbox with 3 params and no output schema, the description covers everything an agent needs before a first call: available in-scope helpers, defaults (5 pages, concurrency 8, 300s, 500 units), failure modes, and how results are returned. Nothing material is missing.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description earns above that: it clarifies that code is an async function body where you use await and return a small result, and that the run stops once budget_units are spent. timeout_seconds is left entirely to the schema, which is acceptable given full coverage.

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?

Opens with a specific verb and resource: run TypeScript that calls the apinoa API and return only what the code prints or returns. That is clearly distinguishable from search_docs (parameter/field lookup) and translate_image, and the operations list makes the scope concrete.

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 it for every data task, from one call to thousands" plus the fan-out/filter/aggregate framing gives strong positive guidance, and it routes to search_docs for parameters, costs and returned fields. It lacks an explicit "don't use this for X" exclusion, but the sibling boundary with search_docs is effectively established.

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

Deploy Server

Other Tools