AI agents and automation

Server routes for agents: see the separate Agent server API matrix (/ai-agents/server-api) for a table of /api/agent/v1/ (capabilities, execute), discovery URLs, and /api/ai/ POST routes—distinct from this URL-manifest guide.

Bring real people, honestly: when a tool runs in the browser, prefer prefilled URLs the human opens in their own tab. Do not use bots or headless browsers to click ads or fake engagement—that breaks trust and conflicts with typical ad network policies on invalid traffic.

Background read: AI at Toolcore — why ordinary browser tools stay central, how optional generation fits, and what honest handoffs look like.

Toolcore is not a general-purpose hosted JSON or image API: there is no endpoint for arbitrary secrets or ad-hoc transforms. Primary integration is the stable HTTPS URLs that open a tool with optional prefilled text via query parameters—plus JSON manifests your agents can fetch to discover paths, key names, and an English system prompt. For headless workflows that need a JSON response, a small Agent remote API under /api/agent/v1 lists supported operations (GET capabilities) and runs them on the server (POST execute)—IP rate-limited, not an open backend. Most tools still run their main work in the visitor's browser; some pages may use optional sign-in or third-party services—see each page.

Hand work to the tool page

You do not need a custom backend for most handoffs. The supported pattern is manifest + prefilled URLs: the assistant fetches JSON, builds a link, and the user’s browser runs formatters, encoders, crypto, diffs, and the rest. That avoids repeating large transforms in chat compared to re-deriving large outputs in chat. Each manifest includes an integration object describing this contract; optional local MCP: bun run mcp (stdio) uses the same non-AI-assisted catalog for clients that speak MCP natively. For a human-facing terminal-style entry on the site, see Pseudo-CLI (open + catalog id)—still the same tool pages under the hood.

Machine-readable manifest

GET /agent-tools.json returns JSON with siteUrl, manifestUrl, per-tool path and prefill rules (including kind: "none" when a page needs upload or interaction that URLs cannot supply). Use it to build links for workflows like JSON format, encrypt and decrypt, or Base64 where prefill is supported.

GET /mcp-tools.json is the same structure with non-AI-assisted tools only (browser-local catalog; no AI-assisted entries). Use it when you want agents or MCP clients to ignore server-side AI helpers. For local stdio MCP, from the Toolcore project root run bun run mcp and point your client at that command.

LLM system prompt (plain text)

GET /llm-prompt.txt is the same English instructions embedded in the manifest as llmSystemPrompt, formatted for copy-paste into assistant or MCP-style client settings. It tells the model to fetch the manifest, build HTTPS URLs with q (percent-encoded UTF-8) or qb (Base64 UTF-8), and to use integration.remoteExecution only for listed POST operations—not to claim server execution for browser-only tools.

Guides for assistant builders & human supervisors

Same product, different angles—pick the page that matches how you discover or explain Toolcore to an agent.

How this differs from a "JSON format API"

Many sites compete on head terms like "json format", "image convert", or "encrypt decrypt" with a classic request/response API. Toolcore's angle is still browser-first and privacy-minded: most work happens in the tab, and agents integrate by returning or opening URLs. The optional /api/agent/v1 path is a narrow, allowlisted escape hatch for automation (JSON in/out, IP rate limits)—not a full public backend. See also About.

Common use cases

  • Fetch /agent-tools.json or /mcp-tools.json and build prefilled HTTPS links so users can run transforms on the actual tool page.
  • For automation that needs a JSON body back, GET /api/agent/v1/capabilities and POST /api/agent/v1/execute for whitelisted deterministic operations (IP rate limits)—see integration.remoteExecution in the manifest.
  • Paste /llm-prompt.txt into assistant settings so the model follows the same URL contract as the manifest.
  • Pair with the pseudo-CLI or direct ?q= links when you want a short, repeatable handoff from automation to UI.

Common mistakes to avoid

  • Treating Toolcore like a fully open backend

    There is no general server API for arbitrary transforms or secrets. /api/agent/v1 only exposes operations returned by GET capabilities (deterministic, JSON in/out, IP rate limits). Most tools still run in the browser via prefilled URLs.

  • Automating ad clicks or other invalid traffic

    Never script or delegate automated clicks on ads or sponsored units. Publishers need authentic human visits; automated engagement typically violates ad network rules and hurts users.

  • Sending AI-assisted tools to clients that must stay offline

    Use /mcp-tools.json for the non-AI-assisted catalog, or filter entries in your client when policy forbids server-side generation.

FAQ

Does Toolcore run my payload on a server?

Most tools execute in the browser. The optional Agent remote API (/api/agent/v1) processes payloads only for whitelisted operations listed in GET capabilities. AI-assisted routes may run server-side—see each tool page and execution labels.

Why prefer links over pasting huge formatted output in chat?

Prefilled URLs let the site do the transform locally, which often saves tokens and avoids duplicating work the UI already performs.