Skip to main content
Glama

call_api

Run live web searches, scraping, speech, LLM calls, invoices, and other external APIs in a single call. Chain sequential, parallel, or conditional steps to automate complex workflows.

Instructions

Primary execution tool. Use this to actually do the job through APIClaw: live web search, scraping, speech, LLM calls, invoices, screenshots, currency, weather, and other external API work. Requires a free workspace; if not authenticated, the response will return action="agent_auth_required" with the CLI command to run (npx @nordsym/apiclaw auth login).

SINGLE CALL: Provide provider + action + params CHAIN: Provide chain array to execute multiple APIs in sequence/parallel with cross-step references.

Chain features:

  • Sequential: Steps execute in order, each can reference previous results via $stepId.property

  • Parallel: Use { parallel: [...steps] } to run concurrently

  • Conditional: Use { if: "$step.success", then: {...}, else: {...} }

  • Loops: Use { forEach: "$step.results", as: "item", do: {...} }

  • Error handling: Per-step retry/fallback via onError

  • Async: Set async: true to get chainId immediately, poll or use webhook

Example chain: chain: [ { id: "search", provider: "brave_search", action: "search", params: { query: "AI agents" } }, { id: "summarize", provider: "openrouter", action: "chat", params: { message: "Summarize: $search.results" } } ]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
asyncNoReturn immediately with chainId. Use get_chain_status to poll or provide webhook.
chainNoExecute multiple API calls as a single chain. Each step can reference previous results via $stepId.property
actionNoAction to perform (e.g., "send_sms", "search", "send_email", "chat", "send_invoice", "convert")
paramsNoParameters for the action. Varies by provider/action.
dry_runNoIf true, shows what WOULD be sent without making actual API calls. Returns mock response and request details. Great for testing and debugging.
timeoutNoMaximum execution time for the entire chain in milliseconds
webhookNoURL to POST results when async chain completes
providerNoProvider ID (e.g., "openrouter", "brave_search", "elevenlabs", "replicate", "firecrawl", "groq", "frankfurter")
ai_backendNoAI backend making this request (e.g., "claude-3-sonnet", "gpt-4"). Used for analytics.
subagent_idNoOptional subagent identifier for multi-agent tracking
customer_keyNoOptional: Your own API key for providers that require customer authentication (e.g., CoAccept).
confirm_tokenNoConfirmation token from a previous call. Required to execute actions that cost money after reviewing the preview.
continueOnErrorNoContinue chain execution even if a step fails (default: false)
idempotency_keyYesRequired caller-owned operation key. If the outcome is ambiguous, do not submit again; retain this key and request ID for reconciliation.
Behavior3/5

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

With no annotations provided, the description carries the full behavioral burden. It discloses an important auth-related behavior: unauthenicated calls return action="agent_auth_required" plus the CLI command. It also explains chain execution semantics (sequential, parallel, conditional, loops, retry/fallback, async). However, it does not describe general success respont format, potential costs or confirmations for paid actions, or side effects beyond 'actually do the job', so behavioral disclosure is partial.

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?

The description is longer than average, but the complexity of the tool (14 parameters, nested chain schema, multi-step orchestration) justifies it. It front-loads the primary purpose in the first sentence and then organizes the details under clear headings: SINGLE CALL, CHAIN, and chain features. The example is valuable; only minor redundancy with the schema's chain descriptions keeps it from a 5.

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

Completeness3/5

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

Given the tool's complexity, no annotations, no output schema, and generic external-API scope, the description covers auth, call modes, and chain semantics well. However, it does not explain the success response shape, how to handle confirm_token for costly actions (despite the schema mentioning it), or how results are returned for single vs. chain calls beyond vague mentions like chainId. An agent would still have meaningful unknowns about return handling.

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 description coverage is 100%, so the schema already documents all 14 parameters. The description adds meaningful usage semantics beyond the schema: it prescribes the 'provider + action + params' pattern for single calls, explains the chain array with cross-step references ($stepId.property), and gives a concrete two-step example. This materially helps the agent assemble params correctly, especially for chain execution.

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?

The description states a specific, high-level purpose: 'Primary execution tool' for actually doing external API work through APIClaw, with explicit examples (web search, scraping, speech, LLM calls, invoices, screenshots, currency, weather). This clearly differentiates it from sibling informational/management tools like discover_apis, check_balance, list_models, and mission_* tools. It also distinguishes its two invocation modes, single call and chain, without ambiguity.

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?

It gives clear context for when to use the tool: whenever actual execution of external API work is needed, and it explains the single-call vs. chain decision. It also provides essential usage conditions, such as requiring a free workspace and the unauthenticated response behavior. However, it does not explicitly name sibling tools to avoid or give when-not-to-use exclusions beyond its role as the 'primary' execution tool.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nordsym/apiclaw'

If you have feedback or need assistance with the MCP directory API, please join our Discord server