Find and run the tools you need.
Describe the task your application needs to perform. ToolsAPI finds matching tools, shows how to call them and executes the one you choose using your Gomry key. You do not need separate vendor accounts, credentials or invoices for the tools in the catalog.
curl https://api.cloud.gomry.com/v1/toolsapi/discover \
-H "Authorization: Bearer $GOMRY_CLOUD_KEY" \
-H "Content-Type: application/json" \
-d '{
"query": "retrieve recent posts from an account",
"limit": 5
}'Discover, inspect, execute.
Find a tool for recent posts
A monitoring app could ask for tools that retrieve an account’s recent public posts. Discovery ranks matching candidates from the catalog of 1,700+ tools across 55+ vendors.
Prepare the chosen tool’s input
In this example, the app selects Apify’s Tweet Scraper, identified as vendor apify and endpoint /apidojo/tweet-scraper. Inspection shows the information it needs, its input format and price when available. The app uses that tool’s schema to supply the account and requested number of posts.
Run it through Gomry
The app sends the selected vendor, endpoint and prepared input through ToolsAPI, then displays the returned posts in its monitoring panel. Access and billing stay with Gomry, without separate accounts, API keys and invoices for each provider it uses from the catalog.
Inspect the selected tool’s input.
{
"vendor": "apify",
"endpoint": "/apidojo/tweet-scraper"
}The app uses the returned schema to prepare the account selection and post limit for POST /v1/toolsapi/run. It can then display the posts returned by the tool, as illustrated below.
- Account
- Demo account (fictional)
- Post text
- Our new opening hours start Monday.
- Used in the app
- A row in the account’s recent-posts panel.
ToolsAPI passes the prepared input to the selected tool. Other tools can require different fields and formats; the shared key does not translate those inputs automatically.
Use the tool’s answer, not just the run status.
A completed run can contain an upstream response saying that no match was found. That can be a valid result, not a reason to repeat the purchase. Your application should distinguish the run’s status from the underlying tool’s answer.
Some executions return a running job. Retrieve the result later through GET /v1/toolsapi/runs/{runId}; polling has no additional charge. An assistant or background worker can use that pattern while your application keeps control over what runs.
Separate lookups from execution costs.
| Operation | Price | What determines usage |
|---|---|---|
| Discovery or inspection | 0.2¢ per lookup | Each discovery or inspection request |
| Tool execution | Variable, metered usage | The selected tool and the work or results it returns |
| Poll an existing run | No charge | Retrieving the existing run, not starting it again |
The meteredMicroUsd amount returned with an execution is its cost record. A catalog price may be an estimate or undisclosed; for tools priced per result, the total depends on how many results come back. Do not treat an unknown price as zero.
Use the project’s monthly budget cap as a spending control. A catalog estimate does not guarantee a per-call total.
Build with ToolsAPI.
Enable ToolsAPI for your project and issue a key with the permissions needed for discovery and inspection, execution, or both. Send it as a Bearer token. Open Services in the Cloud console to review the available operations before configuring a run.