NeuralVerge MCP server gives MCP-compatible agents tools to retrieve verified structured data, run searches/extractions, enrich contacts, and start/poll async research or agent workflows.
Synchronous web search (run_search) and URL extraction (run_extract).
Async AI research and saved-agent runs (run_research, run_agent) with get_session_status polling.
LinkedIn lookup/search for profiles, companies, people, and company employees.
Email validation, email enrichment, email finder, phone enrichment, and US phone validation/enrichment.
Crunchbase company data lookup.
Per README, the full NeuralVerge server exposes 342 tools covering e-commerce, marketplaces, company registries, startup/funding, product reviews, social/enrichment, and more.
Provides access to Crunchbase data for company research, enabling enrichment and lookup of company information through the NeuralVerge API.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@NeuralVerge Research the latest trends in renewable energy and provide a structured report"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The data layer for agentic AI.
One API and MCP server that gives an agent verified, structured, cited facts about the real world, mid-task. Agents don't need search results or raw HTML — they need a finished answer, from one API instead of five vendors.
NeuralVerge draws structured data from 300+ sources — e-commerce marketplaces, corporate registries, startup and funding data, company intelligence, product reviews, enrichment and social — plus the open web, all in one request format. This MCP (Model Context Protocol) server exposes Search, AI Extract and every Data Source as tools, so any MCP-compatible client (Claude, ChatGPT, Gemini, Cursor and others) can call them directly. No scrapers, no pipelines, no glue code. Plans from $50/month.
The real world, structured. E-commerce, company and people data from marketplaces, official registries and vertical sources, not just the web — all returned as JSON.
One API instead of five. Search, extraction and enrichment on one key and one balance, with one request format and no per-source fees or separate contracts.
Agent-native. Tools are available to the agent mid-task over MCP, with no glue code.
Cost you control. Points-based pricing: extraction and search at 5 points per call, plans from $50/month (see Pricing).
Teams use NeuralVerge for agentic products, go-to-market, outbound, market research, competitor analysis, brand monitoring, public procurement, e-commerce intelligence, due diligence, KYC/KYB and recruiting.
Related MCP server: Mixpeek MCP Server
Before installing, you need a NeuralVerge account and an API key:
Sign up at app.neuralverge.ai (or via neuralverge.ai → "Get started").
Choose a plan (see Pricing below) — this determines your monthly points allowance.
Generate an API key from your account/API settings in the app.
Use that key as NEURALVERGE_API_KEY in the Configuration step further down.
NeuralVerge exposes its data layer as a remote Model Context Protocol (MCP) server, so any MCP-compatible client — Claude, ChatGPT, Gemini, Cursor, or a custom agent — can call Search, AI Extract, and every Data Source (including marketplaces and product reviews) directly as tools, without writing any HTTP integration code. See the official page: docs.neuralverge.ai/mcp-server.
This repository is a self-hosted equivalent of that server: same tool names, same input schemas, same behavior, and it can run either as a local stdio process or as a Streamable HTTP server. Notes:
AI Research is not available over MCP: a research run is asynchronous, while an MCP tool has to return its result inside the call. Start research runs over the REST API instead.
Total tool count: 342 — run_search, run_extract and every Data Source endpoint.
Get an API key. In the NeuralVerge dashboard open Settings → API, click Create API Key, and copy the key. Keep it private — it is the only thing that authenticates the connection.
Point your client at a server. Either use NeuralVerge's hosted endpoint, or run this repository (see Installation and Transports & client compatibility).
Hosted endpoint, Claude Code (sign in with OAuth from /mcp; add --header "Authorization: Bearer YOUR_API_KEY" for CI or headless use):
claude mcp add --transport http neuralverge https://mcp.neuralverge.ai/mcpHosted endpoint, Cursor and other JSON clients (omit headers to sign in with OAuth instead of an API key):
{
"mcpServers": {
"neuralverge": {
"url": "https://mcp.neuralverge.ai/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_KEY"
}
}
}
}This repository, Claude Code (local stdio):
claude mcp add neuralverge -e NEURALVERGE_API_KEY=YOUR_API_KEY -- node /absolute/path/to/MCP/dist/index.jsLet the agent call tools. Start a new conversation and ask for something that needs data, for example: "Find the registered address of Škoda Auto in the Czech company registry." The agent picks the right tool, calls it mid-task, and answers from the result.
https://mcp.neuralverge.ai/mcpThe hosted server speaks MCP's Streamable HTTP transport and is stateless — each request is handled independently, with no session to keep alive between calls. Requests must include:
Accept: application/json, text/event-streamThe earlier endpoint, https://api.neuralverge.ai/functions/v1/mcp-server, still works with an API key but does not support sign-in. Use https://mcp.neuralverge.ai/mcp for new connections.
The hosted server accepts two kinds of credentials, both sent as Authorization: Bearer … and both billed to your organization:
Sign in with OAuth (recommended). Clients that support MCP authorization — Claude, ChatGPT, Claude Code, Cursor, VS Code, Windsurf, Gemini CLI and others — discover NeuralVerge's sign-in automatically: add the URL with no credentials and approve access in the browser window that opens (OAuth 2.1, dynamic client registration, PKCE S256). Each connection appears under Settings → API in the dashboard with a label starting with Connector:; the key does not expire, so revoke it there to disconnect a client. Removing the server from the client alone does not revoke it.
API key. For clients without browser sign-in, create a key under Settings → API (see docs.neuralverge.ai/authentication) and send Authorization: Bearer YOUR_API_KEY — the same key the REST API uses.
Listing tools (initialize, tools/list) works without credentials; calling a tool requires them, otherwise the hosted server answers 401 Unauthorized with a WWW-Authenticate header pointing OAuth-capable clients to the sign-in flow. When you run this repository instead, the key is passed to the server process as NEURALVERGE_API_KEY (see Configuration); there is no OAuth flow.
tools/list returns all 342 tools in one response — several hundred kilobytes of JSON. Three things follow from that:
A model pays for those definitions in context on every conversation that has the server attached.
Clients that limit the number of active tools will load only some of them, and the rest will be invisible to the model. Windsurf, for instance, allows 100 at a time.
Every tool is stateless, read-only and independent of the others (and is annotated readOnlyHint here), so a client can run several calls in parallel.
If you only need a few sources, attach the server to a client that lets you pick tools, or proxy it and expose the subset you use.
Every tool returns its result directly in the tool response — there is no session to poll. A scrape that hits its time budget returns partial: true with the records collected so far, so a long run degrades to a shorter result instead of failing.
Claude Code, Cursor and other JSON-config clients — see the Quickstart above.
Claude, ChatGPT — add a custom connector / MCP server pointing at the hosted endpoint above and choose OAuth (leave client ID and secret empty; the client registers itself). To use your own deployment of this server in HTTP mode instead, see Streamable HTTP.
Any other Streamable HTTP client — point it at the URL; if it supports MCP authorization it will offer to sign in, otherwise set Authorization: Bearer YOUR_API_KEY. Clients that only speak SSE or stdio can use an MCP proxy such as mcp-remote. Step-by-step setup for every client is on Connect MCP.
MCP Inspector — run npx @modelcontextprotocol/inspector, choose the Streamable HTTP transport, connect to https://mcp.neuralverge.ai/mcp, and sign in with OAuth or set the Authorization header to explore and test tools interactively.
curl -X POST "https://mcp.neuralverge.ai/mcp" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "run_email_validation",
"arguments": { "email": "john@example.com" }
}
}'A tool call without an Authorization header fails the whole request with 401 Unauthorized; a key that is invalid or revoked is reported inside the tool result instead — remove and re-add the server in your client to sign in again. Once a request is authenticated, errors from an individual tool call (invalid parameters, 402 Payment Required for usage limits, upstream failures, and so on) are returned inside the MCP tool result with isError: true rather than as an HTTP failure — this lets the calling model see and react to the error instead of the whole request failing. The underlying status codes are the same ones described in Errors & Rate Limits and in Error handling below.
The server exposes 342 tools — one per NeuralVerge API endpoint (Search, AI Extract and every Data Source), as listed below. AI Research is not available over MCP. The tool list is generated from the official OpenAPI spec, so input schemas (types, enums, min/max, required fields) match the REST API exactly.
Every tool returns its result synchronously (a scrape that hits its time budget returns partial: true with the records collected so far). Tool names follow the endpoint path: POST /functions/v1/run-amazon-product-search → run_amazon_product_search.
Context size: all 342 tool definitions together are large. If your client caps active tools or you want to save context, enable only the tools you need in the client's tool picker.
342 tools, generated by npm run generate from the NeuralVerge OpenAPI spec. Required parameters are marked with *.
Tool | Description | Parameters |
| Runs a web search and returns a structured search payload. |
|
Tool | Description | Parameters |
| Loads a page by URL and extracts structured data. |
|
Tool | Description | Parameters |
| Looks up a LinkedIn profile and returns contact details, including email when available. |
|
| Finds a LinkedIn profile by company name or domain and full name. |
|
| Searches LinkedIn companies by query and optional filters. |
|
| Searches LinkedIn people using optional query terms and advanced filters. |
|
| Searches LinkedIn employees for one or more companies using people-style filters. |
|
Tool | Description | Parameters |
| Enriches a known email address with profile-related data when available. |
|
| Validates an email address and returns deliverability signals. |
|
| Finds a professional email address using company domain, first name, and last name. |
|
| Enriches a known phone number with profile data when available. |
|
| Validates and enriches a US phone number with carrier and activity details. |
|
Tool | Description | Parameters |
| Fetches structured company data from a Crunchbase company URL. |
|
Tool | Description | Parameters |
| Search Amazon and extract product listings (title, URL, price, rating) across paginated results. 1 point per returned record. |
|
| Get full Amazon product details by ASIN: title, brand, price, images, rating, features, and seller. Flat 5 points per successful run. |
|
| Get all marketplace offers for an Amazon product by ASIN: price, condition, seller, and delivery. Flat 5 points per successful run. |
|
| Get an Amazon seller profile by seller ID: name, rating, business details, and contact info. Flat 5 points per successful run. |
|
| List products sold by an Amazon seller's storefront: title, URL, price, rating, and image. 1 point per returned record. |
|
| Get the full eBay browse category tree: every department, category, and subcategory. Flat 5 points per successful run. | |
| Get full eBay listing details by item ID: title, price, condition, images, and seller. Flat 5 points per successful run. |
|
| Search active eBay listings by keyword: title, price, condition, and seller summary. 1 point per returned record. |
|
| Get eBay catalog product details by ePID: brand, model, rating, price range, and specs. Flat 5 points per successful run. |
|
| Get buyer reviews for an eBay catalog product by ePID: rating, text, and author. 1 point per returned record. |
|
| Get an eBay seller/store profile by username: feedback, ratings, and store details. Flat 5 points per successful run. |
|
| Get feedback reviews received by an eBay seller: rating, reviewer, and related item. 1 point per returned record. |
|
| List active eBay listings for a seller: title, price, condition, and image. 1 point per returned record. |
|
| Get full Walmart product details by item ID: brand, price, rating, and specifications. Flat 5 points per successful run. |
|
| Search Walmart products by keyword: title, price, rating, and seller. 1 point per returned record. |
|
| Get customer reviews for a Walmart product by item ID: rating, text, and author. 1 point per returned record. |
|
| Get a Walmart marketplace seller profile by seller ID: rating, location, and contact info. Flat 5 points per successful run. |
|
| List products from a Walmart seller's storefront: title, price, rating, and availability. 1 point per returned record. |
|
| Get AliExpress product details by ID: title, price, images, and store. Flat 5 points per successful run. |
|
| Search AliExpress products by keyword: title, price, and image. 1 point per returned record. |
|
| Get buyer reviews for an AliExpress product by ID: rating, text, and buyer details. 1 point per returned record. |
|
| Search Alibaba products by keyword: price, MOQ, supplier, and certifications. 1 point per returned record. |
|
| Get full Alibaba product details by ID or URL: price tiers, MOQ, attributes, variants, and supplier. Flat 5 points per successful run. |
|
| Get the Avito category tree: departments and sub-categories with id, name, alias (URL slug for the category filter), parent id, level and browse URL. 5 point per returned record. | |
| Get a full Avito listing by id or URL: title, price (RUB), description, specification params, category and breadcrumbs, address and coordinates, view counts, posting time, photos and seller. Flat 5 points per successful run. |
|
| Search Avito listings by keyword with region, category, price range, sort, seller type, Avito Delivery and attribute filters. Returns title, price, location, coordinates, image and seller for each listing. 1 point per returned record. |
|
| Get an Avito seller (brand page) by slug or URL: name, type, rating, review count, followers, active listing count, registration date and badges. Flat 5 points per successful run. |
|
| Directory of ~700 Craigslist regional sites with alias (the area value for searches), area code, hostname, country, region, coordinates, timezone and sub-areas. Flat 5 points per successful run. |
|
| Every Craigslist posting category with its alias (the category value for searches), description and section. Flat 5 points per successful run. |
|
| Full Craigslist posting by id or URL: title, price, body text/HTML, category attributes with matching search filters, decoded VIN spec for vehicles, hiring company for jobs, images, location and dates. Flat 5 points per successful run. |
|
| Search live Craigslist postings in any regional site by keyword, category, area/sub-area/postal/coordinates and 60+ vehicle, motorcycle, boat, housing, job, gig and event filters; returns title, price, date, location, images and category facets. 1 point per returned record. |
|
| All postings published by the seller of a given Craigslist posting (a dealer's, landlord's or shop's full inventory). 1 point per returned record. |
|
| Get full Flipkart product details by item id or product URL: title, brand, price, MRP, discount, images, color, rating, category, breadcrumbs, availability, condition and recent reviews. Flat 5 points per successful run. |
|
| Get customer reviews for a Flipkart product: rating, title, text, author, date, location, certified-buyer flag, helpful/downvote counts and photos. 1 point per returned record. |
|
| Search Flipkart products by keyword: id, title, brand, price, MRP, discount, image, key specs, rating and review counts. 1 point per returned record. |
|
| Get the Flipkart seller offering a given product: name, rating, years on Flipkart, units sold, quality/speed scores, product/service quality ratings and description. Flat 5 points per successful run. |
|
| Get the Hepsiburada category tree for a category id or URL: the path from the top-level department down to the category, with its nested children (id, name, alias, level, url). Flat 5 points per successful run. |
|
| List products in a Hepsiburada category with filters (brand, seller, color, price range, minimum rating, fast delivery, discounted, photo reviews, authorized sellers) and sorting. Returns id, name, brand, price, list price, discount, image, rating and seller. 1 point per returned record. |
|
| Get a Hepsiburada merchant (store) by slug or store URL: id, name, alias, url and number of products. Flat 5 points per successful run. |
|
| List products sold by a Hepsiburada merchant with filters (brand, color, price range, minimum rating, fast delivery, discounted, photo reviews) and sorting. 1 point per returned record. |
|
| Get full Hepsiburada product details by SKU, product group id or URL: name, brand, price, list price, discount, images, video, rating, stock, specs, variants, categories, the winning seller and other sellers. Flat 5 points per successful run. |
|
| Get customer reviews for a Hepsiburada product (aggregated across its variants): rating, text, author, date, verified purchase, helpful count, per-feature ratings, keywords and photos. Sort by most helpful or most recent. 1 point per returned record. |
|
| Search Hepsiburada products by keyword with filters (brand, seller, color, price range, minimum rating, fast delivery, discounted, photo reviews, authorized sellers) and sorting. 1 point per returned record. |
|
| List all sellers (merchants) offering a Hepsiburada product: seller id, name, price, list price, rating, city, shipping flags and which seller wins the buybox. Flat 5 points per successful run. |
|
| Full Kleinanzeigen category tree: id, name, alias, URL and parent id for every department and subcategory. Flat 5 points per successful run. | |
| Get one Kleinanzeigen ad by id or URL: price, description, location, attributes, images and seller. Flat 5 points per successful run. |
|
| Search live Kleinanzeigen ads by keyword with category, price, condition, seller type, shipping and sort filters. 1 point per returned record. |
|
| Related ads Kleinanzeigen shows on an ad's page, by ad id or URL. 1 point per returned record. |
|
| Get one Kleinanzeigen seller by user id or profile URL: type, active since, followers and badges. Flat 5 points per successful run. |
|
| A seller's active Kleinanzeigen ads by user id or profile URL. 1 point per returned record. |
|
| Get the leboncoin category tree (id, name, slug, parent and nested subcategories). With include_filters enabled, the first category also carries the full catalog of search filters and their enum values. 5 point per returned record. |
|
| Get a full leboncoin ad by ID (or listing URL): title, description, price (EUR), category, category attributes, images, location, publication and expiry dates, and seller. Flat 5 points per successful run. |
|
| Get the 'annonces similaires' recommended for a leboncoin ad (by ID or URL): title, price, attributes, images, location and seller. 1 point per returned record. |
|
| Resolve a French place name or postcode into leboncoin location objects: label, city, zipcode, department/region id and coordinates. 1 point per returned record. |
|
| Get a leboncoin professional store by store ID, seller UUID or store URL: name, SIREN/SIRET, activity sector, description, opening hours, website, address, rating, services and team. Flat 5 points per successful run. |
|
| Get the curated customer reviews leboncoin shows for a professional store (author, rating, text, date, source: Google Maps / Opinion System). 1 point per returned record. |
|
| Browse leboncoin's professional-stores directory by activity sector: id, name, activity sector, city, department and region. 1 point per returned record. |
|
| Get a Mercari (Japan) item by id or URL: title, description, price in JPY, status (on sale / sold out), photos, brand, category path, condition, shipping payer/method/origin/days, likes, comments, seller (name, reviews, star rating, verified) and item features. Flat 5 points per successful run. |
|
| Search Mercari (Japan) items by keyword with category, sort, status and price filters. Returns items with id, URL, name, price (JPY), status, thumbnail and photo. 1 point per returned record. |
|
| Products in a Newegg category by category id or category page URL: price, rating, seller and stock, with sort. 1 point per returned record. |
|
| Get one Newegg product by item number or URL: price, rating, specifications, images, offers price range and seller. Flat 5 points per successful run. |
|
| Every marketplace buying option for a Newegg product: seller, price, shipping, condition and ships-from. 1 point per returned record. |
|
| Owner reviews for a Newegg product: rating, title, text, pros, cons, author, date and helpful votes. 1 point per returned record. |
|
| Search Newegg products by keyword with sort: price, rating, seller and stock. 1 point per returned record. |
|
| Get one Newegg marketplace seller store by store key or URL: rating, followers, badges, legal name and location. Flat 5 points per successful run. |
|
| A Newegg marketplace seller's products by store key or store URL. 1 point per returned record. |
|
| Full category tree of an OLX marketplace: id, name, alias, parent id, depth, child ids, URL and live offer count. 5 point per returned record. |
|
| Category-specific search filters of an OLX category (keys, types, allowed values and ranges) to use in offers search. 5 point per returned record. |
|
| Get one OLX ad by id or URL: price, description, location with coordinates, photos, attributes and seller. 5 point per returned record. |
|
| Search live OLX ads by keyword with category, price, condition, seller type, location, delivery and sort. 1 point per returned record. |
|
| OLX geography: top-level regions or the cities of one region, with ids and coordinates for offers search. 5 point per returned record. |
|
| Get an OLX seller profile by id, uuid or profile URL: account type, registration, last seen, response time and business details. 5 point per returned record. |
|
| A seller's active OLX offers by user id, uuid or profile URL, with category filter and sort. 1 point per returned record. |
|
| Get one Poshmark listing by id or URL: price, brand, size, colors, category, photos, likes/comments, seller and the likers/comments shown on the page. Flat 5 points per successful run. |
|
| Comments on a Poshmark listing (author, text, date), by listing id or URL. 1 point per returned record. |
|
| Users who liked a Poshmark listing (handle, name, avatar), by listing id or URL. 1 point per returned record. |
|
| Listings Poshmark shows as related to a listing, by listing id or URL. 1 point per returned record. |
|
| Search live Poshmark listings by keyword with department, category, brand, size, color, price, condition, shipping, availability and sort filters. 1 point per returned record. |
|
| Get a Poshmark seller's public closet profile by username or URL: bio, location, followers/following/listing counts, items sold and activity. Flat 5 points per successful run. |
|
| Followers of a Poshmark closet (handle, name, avatar), by username or URL. 1 point per returned record. |
|
| Users a Poshmark closet follows (handle, name, avatar), by username or URL. 1 point per returned record. |
|
| Listings in a Poshmark closet by username or URL, with department, category, brand, size, color, price, condition, shipping, availability and sort filters. 1 point per returned record. |
|
| Search Poshmark closets by name or handle (username, name, avatar, home region). 1 point per returned record. |
|
| Rakuten Ichiba genre tree: the top-level genres, or one genre by id with its breadcrumb path and child genres (with item counts). Flat 5 points per successful run. |
|
| Get one Rakuten Ichiba item by shop_code/item_code or URL: price range, subscription price, points, shipping, images, rating, category, shop and SKU variants. Flat 5 points per successful run. |
|
| Customer reviews of a Rakuten Ichiba item by shop_code/item_code or URL: rating, text, author, dates, helpful count, purpose tags, SKU, media and shop replies. 1 point per returned record. |
|
| Search live Rakuten Ichiba items by keyword with sort, condition, price range and genre filters. 1 point per returned record. |
|
| Get one Rakuten Ichiba shop storefront by shop_code or URL: name, description, logo, cover, rating and review count. Flat 5 points per successful run. |
|
| The item catalog of a Rakuten Ichiba shop by shop_code or URL: title, price range, image, points, shipping, rating, category. 1 point per returned record. |
|
| Get one Shopify collection by store domain and handle: title, description, image, product count and timestamps. 5 point per returned record. |
|
| Products of a Shopify collection with options, variants, prices and availability. 1 point per returned record. |
|
| Get one Shopify product by store domain and handle: brand, type, tags, images, options and all variants with price, SKU, barcode, availability and stock. 5 point per returned record. |
|
| List all products of a Shopify store (not a keyword search) with variants, prices and availability. 1 point per returned record. |
|
| List products of a Target category by browse node id or category URL with a sort order. 1 point per returned record. |
|
| Get one Target product by TCIN or URL: price, ratings breakdown, images, specifications, features, variants, dimensions and return policy. Flat 5 points per successful run. |
|
| Customer questions and their answers for a Target product by TCIN or URL. 1 point per returned record. |
|
| Related products Target shows on a product page: alternatives, guests also viewed, complementary, deals, top performing, new arrivals, similar. 1 point per returned record. |
|
| Customer reviews of a Target product by TCIN or URL, newest first. 1 point per returned record. |
|
| Search live Target products by keyword with a sort order (relevance, featured, price, rating, bestselling, newest). 1 point per returned record. |
|
| Trendyol category tree: 10 departments with nested subcategories (id, name, alias, parent id, URL). Pass a category id or alias to get just that subtree. 5 point per returned record. |
|
| Get one Trendyol product by contentId or URL: price, brand, rating, attributes, variants, seller and other sellers. Flat 5 points per successful run. |
|
| Customer reviews for a Trendyol product by contentId or URL: rating, text, author, date, likes, seller and photos. 1 point per returned record. |
|
| All sellers offering a Trendyol product by contentId or URL, for price comparison: price, score, stock, free shipping and which offer is featured. Flat 5 points per successful run. |
|
| Get one Trendyol seller (store) by id or store URL: name, city, score, product count, verified status and shipping/response metrics. Flat 5 points per successful run. |
|
| A seller's storefront products on Trendyol by seller id or store URL: name, brand, price, rating, image. 1 point per returned record. |
|
| Search live Vinted items by keyword on any Vinted market, with category, brand, size, condition, color, material and price filters. 1 point per returned record. |
|
| Get a Vinted member profile by user id or member URL: location, reputation, feedback and item counts, followers, verification and bundle discounts. Flat 5 points per successful run. |
|
| Feedback (reviews) a Vinted member has received: text, rating, reviewer, the seller's reply and date. 1 point per returned record. |
|
| A Vinted member's current wardrobe: title-level data, prices, brand, size, condition, photos, favourites and reserved/closed/hidden flags. 1 point per returned record. |
|
| Get full Wayfair product details by SKU (or product URL): title, brand, price, list price, discount, rating with per-star breakdown, images, variants, verified status, availability and category. Flat 5 points per successful run. |
|
| Search Wayfair products by keyword. Returns products with title, brand, price, list price, currency, discount, rating, review count and images. 1 point per returned record. |
|
| Get a Wayfair brand (seller) by id or brand page URL: name, description, logo image, alias and the brand's collections. Flat 5 points per successful run. |
|
| Yahoo! Auctions Japan category tree, one level at a time: pass a parent category id (0 for the top-level categories) to get its direct sub-categories (id, Japanese name, URL, parent id). 5 point per returned record. |
|
| Get one live or completed Yahoo! Auctions Japan listing by auction id or URL: price, bids, condition, category, description, photos, shipping, payment methods, highest bidders and seller. Flat 5 points per successful run. |
|
| Search completed Yahoo! Auctions Japan auctions by keyword and see the price each item actually sold for, with sold-price, condition, region, seller-type and sort filters. 1 point per returned record. |
|
| Search live Yahoo! Auctions Japan listings by keyword and/or category with price, buy-it-now, condition, region, seller, listing-type, appraisal, shipping filters and sort. 1 point per returned record. |
|
| Get a Yahoo! Auctions Japan catalog product by id or URL: lowest current and buy-it-now price and the live auctions matched to that product. Flat 5 points per successful run. |
|
| Get a Yahoo! Auctions Japan seller profile by seller id or URL: display name, rating count, positive-feedback percentage, store/verification badges and profile message. Flat 5 points per successful run. |
|
| A seller's live Yahoo! Auctions Japan listings by seller id or URL, with keyword, category, price, condition, region and sort filters. 1 point per returned record. |
|
| Feedback comments left for a Yahoo! Auctions Japan seller: verdict, author, auction, comment text and relative date; filter by role and verdict. 1 point per returned record. |
|
| Aggregated Yahoo! Auctions Japan feedback score of a seller: total and positive percentage as seller/buyer plus positive/neutral/negative counts over the last week, month, 6 months, 100 and 1000 transactions. Flat 5 points per successful run. |
|
| List Yandex Market products in a catalog category by id or URL, with sort, price, condition, payment, rating and brand filters. 1 point per returned record. |
|
| Get one Yandex Market product by id or URL: title, brand, price, rating, category breadcrumbs, seller and spec table. Flat 5 points per successful run. |
|
| Search Yandex Market products by keyword with sort, price, condition, payment, rating, brand and seller filters. 1 point per returned record. |
|
| Get products of a Zalando brand by brand alias or brand page URL: name, brand, price, list price, discount, currency, image, silhouette, gender, flags and sizes. 1 point per returned record. |
|
| Get full Zalando product details by product URL: name, brand, colour, price, list price, discount, 30-day lowest price, images, description, category, stock, sizes with stock levels, attributes (material, care, details) and colour variants. Flat 5 points per successful run. |
|
| Get related products from a Zalando product page (similar, same brand, cross-sell and sponsored recommendations): name, brand, price, discount, image, stock and reason. 1 point per returned record. |
|
| Search Zalando products by keyword with optional brand, size, colour, price range and sort filters. Returns name, brand, colour, gender, price, list price, 30-day lowest price, discount, image and sponsored flag. 1 point per returned record. |
|
Tool | Description | Parameters |
| Search Capterra software products by keyword: name, rating, review count, and image. 1 point per returned record. |
|
| Get full Capterra product details by id or URL: vendor, pricing, ratings, and features. Flat 5 points per successful run. |
|
| Get user reviews for a Capterra product by id or URL: rating, pros/cons, and author. 1 point per returned record. |
|
| List Capterra software categories: name, alias, and canonical URL. Flat 5 points per successful run. | |
| List Capterra products within a software category, ranked as Capterra ranks them. 1 point per returned record. |
|
| Search Gartner Peer Insights products by keyword: name, vendor, and review count. 1 point per returned record. |
|
| Get full Gartner Peer Insights product details by alias or URL: vendor, ratings, and company profile. Flat 5 points per successful run. |
|
| Get a Gartner Peer Insights vendor profile by alias or URL: markets, products, and ratings. Flat 5 points per successful run. |
|
| Get the full Gartner Peer Insights category and market taxonomy. Flat 5 points per successful run. | |
| Get a Gartner Peer Insights market profile by alias or URL: features, research, and lessons learned. Flat 5 points per successful run. |
|
| List ranked Gartner Peer Insights products within a market, with ratings and vendors. 1 point per returned record. |
|
| Search Gartner Peer Insights markets (software categories) by keyword. 1 point per returned record. |
|
| Search Trustpilot businesses by keyword: name, domain, rating, and review count. 1 point per returned record. |
|
| Get full Trustpilot business profile by domain or URL: rating breakdown, claim status, and reply behavior. Flat 5 points per successful run. |
|
| Get customer reviews for a Trustpilot business by domain or URL: rating, text, and author. 1 point per returned record. |
|
Tool | Description | Parameters |
| Get one company from the Australia registry (ASIC / ABN) by registration number or registry URL: name, status, registration date, address and legal form. Flat 10 points per successful run. |
|
| Search the Australia company registry (ASIC / ABN) by company name: name, registration number, status, address and link. 1 point per returned record. |
|
| Get one company from the Brazil registry (CNPJ / Receita Federal) by registration number or registry URL: name, status, registration date, address and legal form. Flat 5 points per successful run. |
|
| Get one company from the Denmark registry (CVR) by registration number or registry URL: name, status, registration date, address and legal form. Flat 5 points per successful run. |
|
| Search the Denmark company registry (CVR) by company name: name, registration number, status, address and link. 1 point per returned record. |
|
| Get one company from the Estonia registry (e-Business Register) by registration number or registry URL: name, status, registration date, address and legal form. Flat 5 points per successful run. |
|
| Search the Estonia company registry (e-Business Register) by company name: name, registration number, status, address and link. 1 point per returned record. |
|
| Get one company from the France registry (RNE / INPI) by registration number or registry URL: name, status, registration date, address and legal form. Flat 30 points per successful run. |
|
| Search the France company registry (RNE / INPI) by company name: name, registration number, status, address and link. 1 point per returned record. |
|
| Get one company from the New Zealand registry (Companies Register) by registration number or registry URL: name, status, registration date, address and legal form. Flat 5 points per successful run. |
|
| Search the New Zealand company registry (Companies Register) by company name: name, registration number, status, address and link. 1 point per returned record. |
|
| Get one company from the United Kingdom registry (Companies House) by registration number or registry URL: name, status, registration date, address and legal form. Flat 30 points per successful run. |
|
| Search the United Kingdom company registry (Companies House) by company name: name, registration number, status, address and link. 1 point per returned record. |
|
| Get one company from the Belgium registry (KBO/BCE) by enterprise number or registry URL: name, status, start date, address, legal form, activities, directors, contact details and establishment units. 10 point per returned record. |
|
| Search the Belgium company registry (KBO/BCE) by company name: name, enterprise number, status, address and link. 1 point per returned record. |
|
| Search the Brazil company registry (CNPJ / Receita Federal data) by company name: name, CNPJ, status and link. 1 point per returned record. |
|
| Get one company from the Norway registry (Brønnøysundregistrene, Enhetsregisteret) by organisation number or registry URL: name, status, registration date, address, legal form, industry codes and board/signatory roles, share capital, employees, previous names, auditor, liens and related units. 5 point per returned record. |
|
| Search the Norway company registry (Brønnøysundregistrene, Enhetsregisteret) by company name: name, organisation number, postal code and place, and link. 1 point per returned record. |
|
| Get one company from the Colombia registry (RUES, Registro Mercantil) by NIT or registry URL: name, status, registration date, address, legal form, economic activity, legal representation and establishments. Flat 5 points per successful run. |
|
| Search the Colombia company registry (RUES, Registro Mercantil) by name: name, NIT, status, chamber of commerce, category and link. 1 point per returned record. |
|
| Get one company from the Czech Republic commercial register (Justice.cz) by registration number (IČO, 8 digits) or registry URL: name, status, registration date, address and court file number. Also returns legal form, business scope, share capital, officers, shareholders and branches. 5 point per returned record. |
|
| Search the Czech Republic commercial register (Justice.cz) by company name: name, registration number (IČO), status, address and link. 1 point per returned record. |
|
| Get one company from the Latvia registry (Register of Enterprises) by registration number or registry URL: name, status, registration date, address, legal form, capital, officers, shareholders and beneficial owners. Flat 5 points per successful run. |
|
| Search the Latvia company registry (Register of Enterprises) by company name or registration number: name, registration number, status, address and link. 1 point per returned record. |
|
| Get one company from the Poland registry (KRS) by KRS number or registry link: name, status, registration date, address, legal form, NIP/REGON, representatives, capital, shareholders, branches, history. Flat 5 points per successful run. |
|
| Search the Poland company registry (KRS) by company name: name, KRS number, city, register and flags. 1 point per returned record. |
|
| Get one company from the Slovakia Commercial Register (Obchodný register SR) by IČO or registry URL: name, status, registration date, address, legal form, activities and board, with full history. 10 point per returned record. |
|
| Search the Slovakia Commercial Register (Obchodný register SR) by the beginning of the business name: name and link to the registry extract. 1 point per returned record. |
|
| Get one company from the Austria registry (Firmenbuch) by registration number (FN) or registry URL: name, status, legal form, address, previous names and the paid extracts offered. Flat 5 points per successful run. |
|
| Search the Austria company registry (Firmenbuch) by company name or FN: name, registration number, status, seat and link. 1 point per returned record. |
|
| Get one company from the Finland registry (PRH / YTJ) by Business ID (Y-tunnus) or registry URL: name, status, registration date, address, legal form, names, registrations, tax debt status and Business ID history. Flat 5 points per successful run. |
|
| Search the Finland company registry (PRH / YTJ) by company name: name, Business ID, status, municipality and link. 1 point per returned record. |
|
| Get one company from the South Korea registry (DART) by DART corp code, stock code or registry link: name, English name, market, registration numbers, address, industry, established date, representatives, name history and representative history. 15 point per returned record. |
|
| Search the South Korea company registry (DART) by company name or stock code: name, DART corp code, market, stock code and link. 1 point per returned record. |
|
| Get one company from the Netherlands registry (KVK Handelsregister) by KVK number or registry URL: name, status, registration date, address, legal form and establishments. Flat 5 points per successful run. |
|
| Search the Netherlands company registry (KVK Handelsregister) by company name: name, registration number, status, address and link. 1 point per returned record. |
|
| Get one company from the Bulgaria registry (Commercial Register) by UIC (ЕИК) or registry link: name, status, first registration date, address and contacts, legal form, activity, capital and shares, representatives and board, procuracy, trade-undertaking transfers, mergers, predecessors/successors, liquidation, beneficial owners (NPLE), registrar instructions and court case files. 15 point per returned record. |
|
| Search the Bulgaria company registry (Commercial Register) by company name or UIC: name, UIC (ЕИК), legal form and card link. 1 point per returned record. |
|
| Get one organisation from the Cyprus registry (Registrar of Companies, DRCOR) by registration number (HE, EE, AE, S, BN prefix) or registry link: name, status, registration date, registered office, type, previous names, directors / secretaries / partners, annual fees paid and counters. 10 point per returned record. |
|
| Search the Cyprus company registry (Registrar of Companies, DRCOR) by name: name, registration number, type, status and link. 1 point per returned record. |
|
| Get one company from the Croatia registry (Sudski registar) by MBS, OIB or registry link: name, status, registration date, address, legal form, capital, activities, members, supervisory board, representatives, legal relations and the list of filed financial reports. 5 point per returned record. |
|
| Search the Croatia company registry (Sudski registar) by company name: name, MBS, OIB, status, address, court and link. 1 point per returned record. |
|
| Get one company from the Luxembourg registry (LBR / RCS) by RCS number or registry link: name, status (radiée / en faillite), registration and deletion date, address, legal form, trade names, NACE code, and EUID. 5 point per returned record. |
|
| Search the Luxembourg company registry (LBR / RCS) by company name or RCS number: name, RCS number, status (radiée / en faillite) and link. 1 point per returned record. |
|
| Get one company from the Slovenia registry (AJPES PRS) by registration number (matična številka) or registry link: name, short name, status (active/deleted), address, tax and VAT number, number of business units and the list of those units. 10 point per returned record. |
|
| Search the Slovenia company registry (AJPES PRS) by company name: name, short name, registration number (matična številka), status (active/deleted), address, tax/VAT number and link. 1 point per returned record. |
|
| Get one company from the Taiwan registry (MOEA) by 統一編號 or registry link: name, status, registration date, address, company type, capital and shares, representative, business scope, directors, managers, branches, factories, warehouses, stock listing, trademarks and change history. 15 point per returned record. |
|
| Search the Taiwan company registry (MOEA) by company name or 統一編號: name, registration number, status, address, registration authority and link. 1 point per returned record. |
|
| List the announced acts of a Bulgaria company (Commercial Register) by UIC (ЕИК) or registry URL, newest first: announcement date, act type, title and document link (annual reports, notices, reports, current articles). 1 point per returned record. |
|
| List the filings of one Cyprus organisation (Registrar of Companies, DRCOR) by registration number or registry link: file documents, charges and mortgages, translations, annual returns (HE32) or pending services, with form, date and page number. 1 point per returned record. |
|
| List the documents filed in the Czech Republic Collection of Documents (Sbírka listin, Justice.cz) for one company, by IČO or registry URL, newest first: document number, type, description, period, filing dates, pages and link. 1 point per returned record. |
|
| List the announcements (Objave) or the document collection (Zbirka isprava) of one company in the Croatia registry (Sudski registar), newest first: date, type, topic, case number and file link. 1 point per returned record. |
|
| List the filings of one South Korea company (DART) by DART corp code, stock code or registry link, newest first: report id, report name, filer, filing date, correction flag, remarks and link. 1 point per returned record. |
|
| List the RESA publications of one Luxembourg company (LBR / RCS), newest first: publication number, date, type, details and consult mode. 1 point per returned record. |
|
| List the filed annual reports of a Latvia company (Register of Enterprises) by registration number or registry URL, newest first: financial year, type and link. 1 point per returned record. |
|
| List the registry announcements (Kunngjøringer) of a Norway company (Brønnøysundregistrene) by organisation number or registry URL, newest first: date, announcement type and link. 1 point per returned record. |
|
| List the filed financial documents (annual and consolidated statements, auditor opinions, approval resolutions, management reports) and register entries of a Poland company (KRS) by KRS number or registry link, newest first: date, type, period and entry details. 1 point per returned record. |
|
| Annual reports, announcements and registrations of one Danish company (CVR): date, type, description and document links. 1 point per returned record. |
|
| Annual reports and documents of one Estonian company (e-Business Register): date, type, title and download links. 1 point per returned record. |
|
| Documents filed by one New Zealand company (Companies Register): date, type and file links. 1 point per returned record. |
|
| Get one company from the Romania registry data (Ministry of Finance / ONRC) by CUI (CIF): name, status and registration date, address, trade register number, authorization act, phone/fax, tax registrations (profit tax, VAT, social contributions, ...) and the latest filed financial indicators (assets, debts, equity, turnover, profit, employees). 15 point per returned record. |
|
| Search the Romania company registry (Ministry of Finance / ONRC data) by company name: name and CUI. Bucharest by default, add "@ cluj" (county name or code) to the keyword to search another county. All words must appear in the name. 1 point per returned record. |
|
| Filing history of one UK company (Companies House): date, type, description and document link. 1 point per returned record. |
|
| Get one company from the Spain registry (Registro Mercantil, Registradores de España open-data directory) by NIF/CIF or registry link: name, status (Vigente / Liquidada / Concurso), address, legal form, registry office and sheet number, IRUS and EUID identifiers, CNAE/NACE activity, website, special situation, administrators and officers with their roles, and other registry entries under the same NIF such as branches. 10 point per returned record. |
|
| Search the Spain company registry (Registro Mercantil, Registradores de España open-data directory) by company name, brand or NIF: name, NIF/CIF, status, address, legal form, registry office, sheet number, EUID, CNAE activity and link. 2 point per returned record. |
|
| Get one company from the Portugal registry (Registo Comercial publications portal) by NIF/NIPC or registry link: name, legal form, registered seat (street, postal code, locality, parish, municipality, district), number of publications and the newest publication. 15 point per returned record. |
|
| Search the Portugal company registry (Registo Comercial publications portal) by entity name: name, NIF/NIPC, municipality and the date and type of the newest publication. 2 point per returned record. |
|
| List the publications of a Portugal company (Registo Comercial publications portal) by NIF/NIPC or registry link, newest first: date, act type (registry acts, accounts deposits, notices, convocations), municipality and whether a text / attachment exists. 2 point per returned record. |
|
| Get one company from the Sweden registry (Bolagsverket) by organisation number or registry link: name, status history, registration date, address, legal form, municipality and county, special and foreign-language business names. 5 point per returned record. |
|
| Search the Sweden company registry (Bolagsverket) by company name or organisation number: name, organisation number, status, city, legal form and card link. 1 point per returned record. |
|
| List the most recent registry cases of a Sweden company (Bolagsverket) by organisation number or registry URL, newest first: case number, type (annual report, interim report, register update...), status, arrival and registration dates, financial period. 1 point per returned record. |
|
| Get one company from the Argentina registry of legal entities (Registro Nacional de Sociedades, IGJ) by CUIT or registry link: name, company type, contract date, legal and fiscal address, activities and last update. 5 point per returned record. |
|
| Search the Argentina registry of legal entities (Registro Nacional de Sociedades, IGJ) by company name or CUIT: name, CUIT, company type, address, main activity and link. 1 point per returned record. |
|
| Get one federal corporation from the Corporations Canada registry by corporation number or registry link: name, status, incorporation date, registered office address, governing legislation, directors, individuals with significant control, annual filings and name history. 5 point per returned record. |
|
| Search federal corporations in the Corporations Canada registry by name, corporation number or business number: name, corporation number, status, business number and link. 1 point per returned record. |
|
| Certificates and filings of one federal corporation in the Corporations Canada registry: date, type and amendment details. 1 point per returned record. |
|
| Get one company from the Ecuador registry (Superintendencia de Compañías) by expediente number or RUC: expediente, RUC and registered name. 5 point per returned record. |
|
| Search the Ecuador company registry (Superintendencia de Compañías) by company name: expediente number, RUC and name (the registry returns up to 15 matches per search). 1 point per returned record. |
|
| Get one company from the Georgia registry (NAPR) by identification code: name, status and legal form. 5 point per returned record. |
|
| Search the Georgia company registry (NAPR) by company name or identification code: name, registration number, status and legal form. 1 point per returned record. |
|
| Get one company from the Israel registry (Corporations Authority) by company number: Hebrew and English name, status, registration date, address, company type, liability, purpose and last annual report year. 5 point per returned record. |
|
| Search the Israel company registry (Corporations Authority) by company name or company number: name, registration number, status, address, company type and registration date. 1 point per returned record. |
|
| Get one company notice from the Mexican Registro Público de Comercio publications (PSM) by publication number: company name, legal form, publication type, title and date, a link to the published text and the publication history. 5 point per returned record. |
|
| Search Mexican companies by name in the company publications of the Registro Público de Comercio (PSM): name, legal form and the latest publication with its number, type, title and date. 1 point per returned record. |
|
| Get one entity from the Panama Registro Público (Consulta de Folios Suspendidos) by folio or registry link: name, status, register type, incorporation date and status date. Covers suspended, dissolved, merged and closed entities. 5 point per returned record. |
|
| Search the Panama Registro Público (Consulta de Folios Suspendidos) by company name or folio number: name, folio, status, register type, incorporation date and status date. Covers suspended, dissolved, merged and closed entities. 1 point per returned record. |
|
| Get one LEI record from the Global LEI Index by LEI code or search.gleif.org link, with the Current Data tab of the page: names, legal form, registration authority, categories, BIC/ISIN codes, addresses, registration and issuer details, fund and branch relationships, and direct and ultimate parents. 5 point per returned record. |
|
| Search the Global LEI Index by company name or LEI code: LEI, name, LEI status, address, legal form code, creation date, category, jurisdiction, registration dates and managing issuer. Filter by active or inactive LEI, exact LEI status, entity category and country. 1 point per returned record. |
|
| Get one Legal Entity Identifier record by LEI code or lei-lookup.com link: name, entity and LEI status, registration and renewal dates, managing issuer, legal form, registration authority, legal and headquarters addresses, parent companies and the number of subsidiaries. 5 point per returned record. |
|
| Search the public register of Legal Entity Identifiers by company name or LEI code: LEI, name, country, entity status, LEI registration status and link. Filter by entity status (active or inactive), LEI registration status and country. 1 point per returned record. |
|
| Subsidiaries of one legal entity in the LEI register (direct and ultimate children): LEI, name, type of relationship and link. 1 point per returned record. |
|
| All published notices of one company in the Mexican Registro Público de Comercio publications (PSM): assemblies, balances, capital and structure changes, with date, type, title and a link to the published text. 1 point per returned record. |
|
| List the documents in the Slovakia Commercial Register collection of documents (Zbierka listín) for one company, by IČO or registry URL: document name, type, delivery date and whether an electronic copy exists. 1 point per returned record. |
|
Tool | Description | Parameters |
| Get one startup from BetaList by slug or URL: name, tagline, description, makers, topics, launch date, screenshots and similar startups. Flat 5 points per successful run. |
|
| The newest startups on BetaList, newest first: name, tagline, logo and link. 1 point per returned record. |
|
| Search BetaList startups by keyword: name, tagline, logo and link. 1 point per returned record. |
|
| Startups of one BetaList topic (slug like generative-ai, category/topic, or a BetaList topic URL): name, tagline, logo and link. 1 point per returned record. |
|
| Get one company from Dealroom by slug or URL: tagline, HQ, founding year, sector, tier, valuation / revenue / headcount ranges, investors by round, ownership, funding events, alumni founders, footprint and investments. Dealroom shows ranges, not exact values, without a login. Flat 5 points per successful run. |
|
| Search Dealroom companies by keyword and/or tier, sector and country: name, tier, sector, HQ, founding year, numeric valuation and range, logo and link. At least one of keyword / tier / sector / country is required. 1 point per returned record. |
|
| Get one investor from Dealroom by slug or URL: type, HQ, rank, portfolio / unicorn / investment counts, links, biggest holdings, exits, portfolio analysis, market map, similar investors and key people. Flat 5 points per successful run. |
|
| Search the Dealroom investor index by name keyword, type and country, ordered by Dealroom rank: name, type, country, HQ, portfolio companies, rank and link. With no filters it returns the top of the index. 1 point per returned record. |
|
| Get one startup from the EU-Startups database by slug or URL: tagline, description, country, city, tags, founding year, total funding, website, status, social links and related articles. Flat 5 points per successful run. |
|
| Search the EU-Startups startup database by country category (e.g. german-startups) or by keyword: name, city, tags, founding year, logo and link. Provide a country or a keyword. 1 point per returned record. |
|
| Get one investor from the EU-Startups investor database by slug or URL: type, HQ country, website, investment areas, typical investment, funding stages, LinkedIn and contact email. Flat 5 points per successful run. |
|
| Search the EU-Startups investor database by name, type and HQ country: type, HQ, investment areas, typical investment, funding stage and link. All filters are optional. 1 point per returned record. |
|
| AI tool categories of Futurepedia with the number of tools in each and the group they belong to (the top sub-categories shown on the Futurepedia categories page). Optional group filter. Flat 5 points per successful run. |
|
| Get one AI tool from Futurepedia by slug or URL: description, rating and review count, categories, pricing, key features, pros and cons, use cases, pricing plans, rating breakdown and social links. Flat 5 points per successful run. |
|
| Alternatives to one Futurepedia AI tool (slug or URL): name, description, pricing, rating, categories and link. 1 point per returned record. |
|
| User reviews of one Futurepedia AI tool (slug or URL): rating, review text and reviewer name. 1 point per returned record. |
|
| List the AI tools of one Futurepedia category (slug like video-generators or a category URL) with sorting, pricing, feature and verified filters: name, description, pricing, rating, categories and link. 1 point per returned record. |
|
| Get one Indiegogo campaign by slug or URL: goal, funds raised, backers, phase and outcome, category, tags, story, risks, refund policy, stretch goals, creator and the number of perks. Flat 5 points per successful run. |
|
| Search Indiegogo (and Gamefound) projects by keyword and category, phase, benefit, tag, creator and player-count filters: name, tagline, goal, funds raised, backers, phase, dates, creator and link. 1 point per returned record. |
|
| Browse the Indie Hackers Ideas database, optionally by category: company, one-line idea, categories and MRR. 1 point per returned record. |
|
| Get one Indie Hackers post by its slug or URL: title, full text, author, publish date, upvotes, comment count and the product it belongs to. Flat 5 points per successful run. |
|
| List the comments of one Indie Hackers post (threaded: depth and parent id): text, author, upvotes and date. 1 point per returned record. |
|
| Indie Hackers post feeds: the top posts of a week, month or all time, or the newest posts, with author, upvotes and comment counts. 1 point per returned record. |
|
| Get one product from Indie Hackers by slug or URL: name, tagline, description, website, Twitter, self-reported monthly revenue, founders and the product's updates. Flat 5 points per successful run. |
|
| Browse the Indie Hackers products directory by sort, category, business model and monthly revenue range: name, tagline and self-reported revenue. 1 point per returned record. |
|
| Get one Indie Hackers member by username or profile URL: name, bio, products with revenue and the latest activity. Flat 5 points per successful run. |
|
| Get one Kickstarter project by creator/project or URL: goal, pledged, backers, state, dates, creator, category, location, story, risks and counters of rewards, updates, comments and FAQ. Flat 5 points per successful run. |
|
| Search Kickstarter projects by keyword, category, state, staff picks, location and funding ranges: name, blurb, goal, pledged, backers, creator, category and link. 1 point per returned record. |
|
| Get one company from Owler by slug or URL: description, founded year, headquarters, CEO, revenue and employee estimates, full funding rounds with investors, acquisitions, investments, competitors and latest news. Flat 10 points per successful run. |
|
| Competitors of one Owler company (slug or URL): name, link, CEO, revenue, employees, funding, headquarters and sector. 1 point per returned record. |
|
| Latest news about one Owler company (slug or URL): title, summary, publisher, date and link. 1 point per returned record. |
|
| Search Owler companies by name (the site's own suggestion list): company id, name, logo and profile link. 1 point per returned record. |
|
| Get the public profile preview of a company by PitchBook id or URL: description, website, founded year, status, employees, industries, parent company, address, social links, FAQs, the latest deals, competitors, investors, investments, affiliates and patent tables shown in the free preview, verticals, related research and news. Flat 5 points per successful run. |
|
| Get the public profile preview of an investor by PitchBook id or URL: description, website, founded year, status, investor types, address, social links, FAQs, counters (investments, portfolio, exits), the latest investments, exits, co-investors and affiliates shown in the free preview, related research and news. Flat 5 points per successful run. |
|
| Search PitchBook public profile previews by keyword: name, type (company / investor / fund), profile id and link. 1 point per returned record. |
|
| Get one product from PitchWall by slug or URL: tagline, full description with pricing and FAQs, website, topics, publish date, social accounts, screenshots and submitter. Flat 5 points per successful run. |
|
| List the newest PitchWall products, or the products of one topic (tag): name, tagline, website, topics, publish date and link. The topic is optional. 1 point per returned record. |
|
| Products of a Product Hunt category: name, tagline, rating, review count, launches and categories. 1 point per returned record. |
|
| The Product Hunt categories with their sub-categories: name, slug, parent and description. Flat 5 points per successful run. | |
| Products of a Product Hunt collection in the curator's order, with the full list paged beyond the first 20. 1 point per returned record. |
|
| Browse Product Hunt collections page by page, or search them by keyword. 1 point per returned record. |
|
| Browse Product Hunt forum threads page by page, or search them by keyword. 1 point per returned record. |
|
| Top-level comments of a Product Hunt forum thread: text, author, votes, reply count and date, all pages. 1 point per returned record. |
|
| Get one Product Hunt launch by slug or URL: tagline, votes, comments, daily / weekly / monthly rank, dates, topics, link and the product it belongs to. Flat 5 points per successful run. |
|
| Search Product Hunt launches by keyword: name, date and the product behind each launch. 1 point per returned record. |
|
| Launches of a Product Hunt leaderboard (day, week, month or year): rank, name, tagline, votes, comments, topics and product link, beyond the first page. 1 point per returned record. |
|
| Get one product from Product Hunt by slug or URL: tagline, description, website, rating, review count, followers, launches, categories, social links, pros and cons, makers, awards and similar products. Flat 5 points per successful run. |
|
| Alternatives of a Product Hunt product with their rating and similarity score, all pages. 1 point per returned record. |
|
| Customers of a Product Hunt product (products whose makers say they use it) with the shoutout note. 1 point per returned record. |
|
| Launches of a Product Hunt product: votes, comments, ranks and dates, all pages. 1 point per returned record. |
|
| Reviews of a Product Hunt product (all review types): rating, text, reviewer, date and alternatives mentioned, all pages. 1 point per returned record. |
|
| Search Product Hunt products by keyword: name, tagline, rating, review count, logo and link. 1 point per returned record. |
|
| Products of a Product Hunt topic: name, tagline, rating, review count, launches and categories. 1 point per returned record. |
|
| Get one Product Hunt user by username or URL: name, headline, about, followers, submitted launches, products, collections, reviews, links and join date. Flat 5 points per successful run. |
|
| Collections of a Product Hunt user with their size and first products, all pages. 1 point per returned record. |
|
| Comments of a Product Hunt user, taken from their activity feed (comments filter), all pages. 1 point per returned record. |
|
| Launches submitted by a Product Hunt user: votes, comments, ranks and dates, all pages. 1 point per returned record. |
|
| Products in a Product Hunt user's stack with who recommended them. 1 point per returned record. |
|
| Launches a Product Hunt user upvoted, newest first: votes, comments, ranks and dates. The site serves at most the latest 200 upvotes of a user. 1 point per returned record. |
|
| Get one funded business from the Republic Europe (Seedrs) secondary-market page by slug or URL: description, sector, available shares, indicative valuation and its change, eligibility and incorporation date. Flat 5 points per successful run. |
|
| Get one Republic Europe (Seedrs) campaign by slug or URL: raised and target amounts, valuation, equity offered, share price, investors, tax relief, company number, sectors, links, highlights and the pitch text. Flat 5 points per successful run. |
|
| Search the live Republic Europe (Seedrs) campaigns by campaign-name word and sector, impact tag, business type, tax relief and pitch type filters: raised and target amounts, valuation, investors, type, status and link. 1 point per returned record. |
|
| Get one company from Tech.eu Funding Explorer by id or URL: description, location, sectors, every funding round with investors, exit and funding-signal estimates. Flat 5 points per successful run. |
|
| Search European startup exits and M&A (Tech.eu Funding Explorer, CC BY 4.0), newest first: company, date, type, value in EUR and acquirer. 1 point per returned record. |
|
| Get one investor profile from Tech.eu Funding Explorer by name or URL: deals, portfolio, biggest deals, co-investors, sector / stage / country focus. Flat 5 points per successful run. |
|
| Search the Tech.eu investor directory by name: type, number of deals and companies, top sector and active years. 1 point per returned record. |
|
| Search European startup funding rounds (Tech.eu Funding Explorer, CC BY 4.0), newest first: company, amount in EUR, stage, investors, date and source. Filter by country, stage, sector, minimum amount and dates. 1 point per returned record. |
|
| Get one company from There's An AI For That by slug or URL: description, industry, location, website, socials, AI-native flag, employees, valuation, ranks and its tools. Flat 5 points per successful run. |
|
| AI ecosystem ranking of countries from There's An AI For That: region, AI market cap, population, AI investment per capita and the number of companies, organizations, investors, tools, models, papers, devices, robots and fundraises. Optional region filter. Flat 5 points per successful run. |
|
| Get one task (category) from There's An AI For That by slug or URL: number of tools, models, robots and devices, subscribers, most popular tool, subtasks, related tasks and the top tools. Flat 5 points per successful run. |
|
| Get one AI tool from There's An AI For That by slug or URL: tagline, description, website, pricing, rating and its breakdown, views, saves, task, company, country, features, releases, pros and cons, FAQ and counters of alternatives and reviews. Flat 5 points per successful run. |
|
| Alternatives and similar tools of one There's An AI For That tool (top alternatives and "if you liked" recommendations): name, short description, task, price, rating, views and link. 1 point per returned record. |
|
| Reviews and comments of one There's An AI For That tool: text, star rating, date, release, votes and author. 1 point per returned record. |
|
| Search AI tools on There's An AI For That by keyword or task name: name, short description, task, price, rating, views, saves and link. Sorting and tool type apply to task names (for example seo or video editing). Paid placements are skipped. 1 point per returned record. |
|
| Get one company from Tracxn by profile URL or id token: description, website, founding year, location, stage, sectors, total funding, latest round, valuation, investors, revenue band, employee count, competitors, legal entities, board, the 3 latest funding rounds and news. Flat 5 points per successful run. |
|
| Get all funding rounds and the investor list of one Tracxn company (profile URL or id token): date, amount, round name, lead and other investors, plus the first-investment line of the institutional investors. Flat 5 points per successful run. |
|
| Get the companies of a Tracxn list page (an explore list such as Auto Tech startups in India, or a sector /companies page): name, description, founded year, location, stage, total funding, investors, Tracxn score, competitor rank. 1 point per returned record. |
|
| Get one country startup landscape from Tracxn by URL or id token: totals, top companies and investors, recent funding rounds, acquisitions, IPOs and news. Flat 5 points per successful run. |
|
| Get one investor (VC, PE, angel network, family office ...) from Tracxn by profile URL or id token: type, founding year, headquarters, portfolio and unicorn / IPO / acquisition counts, top investments, yearly / stage / sector / geography breakdowns, recent investments, team, co-investors and news. Flat 5 points per successful run. |
|
| Get one registered legal entity from Tracxn by URL or id token: CIN, status, type, incorporation date, registrar, capital, address, brands, business activity, recent filings, directors and signatories. Flat 5 points per successful run. |
|
| Search 21.9M registered legal entities in Tracxn by name or CIN in one of 13 countries (default India): name, CIN, incorporation date, status, associated brands and link. 1 point per returned record. |
|
| Get one founder / angel investor / board member from Tracxn by profile URL or id token: roles, founded companies, board memberships, angel investments, portfolio exits and top news. Flat 5 points per successful run. |
|
| Get one Tracxn sector overview by URL or id token: company / funding / unicorn / IPO / acquisition totals, top companies and investors, founding and funding trends by year and country, recent rounds, acquisitions, IPOs and news. Flat 5 points per successful run. |
|
| List the unicorn startups of a country from Tracxn Unicorn Club (newest first): rank, name, description, founded year, location, stage, sectors, time to unicorn, top investors, employees, total funding, join date. 1 point per returned record. |
|
| Get one WeFunder company by slug or URL: tagline, location, total raised and investors, current round (valuation, minimum investment, closing date), highlights, team, featured investors, memos, perks, FAQ and the latest updates and questions. Flat 5 points per successful run. |
|
| Browse WeFunder campaigns by status, instrument and industry / highlight tags: name, tagline, raise progress, investors, valuation terms, founder and link. 1 point per returned record. |
|
| Get one company from Wellfound by slug or URL: description, size, stage, total raised, funding rounds, founders, tags, locations and open jobs. Flat 5 points per successful run. |
|
| Search Wellfound jobs by role and location: job title, pay, locations, description and the hiring company (size, stage, tags). 1 point per returned record. |
|
| Get one Y Combinator company by slug or URL: one-liner, description, batch, status, website, team size, location, founders with bios, social links, news and Launch YC posts. Flat 5 points per successful run. |
|
| Search the Y Combinator directory by keyword and filters (batch, industry, region, hiring, top company, nonprofit, team size): name, one-liner, batch, status, industries, regions, team size and website. 1 point per returned record. |
|
| Search the public Y Combinator founders directory by name keyword and filters (batch, title, industry, top company): name, title, company, batches, industries and region. 1 point per returned record. |
|
| The country categories of the EU-Startups database with their slugs (use them as the country filter of the directory search), names, links and startup counts. Flat 5 points per successful run. | |
| The list of Wellfound job locations (US cities, US states, countries and other places) with the slug to use as the location in Wellfound jobs search. Optional type and name filters. Flat 5 points per successful run. |
|
When NeuralVerge adds or changes endpoints, regenerate the tools and rebuild:
npm run generate # fetches https://docs.neuralverge.ai/openapi.json -> src/endpoints.generated.ts + README tool list
npm run buildNeuralVerge uses simple, points-based pricing — one pool of points covers search, extraction, and every data source. See neuralverge.ai/pricing for the current numbers.
Plans
Plan | Price | Points / month |
Base | $50/mo | 50,000 |
Core (Popular) | $100/mo | 100,000 |
Pro | $250/mo | 250,000 |
Ultima | $500/mo | 500,000 |
Enterprise | $1,000/mo | 1,000,000 |
Action costs
Action | Cost |
| 5 pts |
| 5 pts |
Data Source tools | priced per endpoint — see each endpoint's page at docs.neuralverge.ai |
| 100 pts per 25 results |
| 30 pts/run + 5 pts/profile |
| 100 pts |
Plans can be changed anytime; the new points allowance applies on the next billing cycle. Points reset every cycle.
Node.js >= 18
A NeuralVerge API key (Bearer token) — see Getting an API key above and docs.neuralverge.ai/authentication
npm install
npm run buildThis compiles TypeScript sources in src/ to dist/.
The server reads its configuration from the environment:
Variable | Required | Description |
| Yes | Your NeuralVerge API bearer token (see Getting an API key). |
| No | Override the NeuralVerge API base URL. Defaults to |
| No |
|
| No | Port for |
| No | HTTP path for the MCP endpoint. Defaults to |
| No | If set, |
Copy .env.example to .env for local reference, but note the server itself reads process environment variables — most MCP clients pass these via their own config, not via a .env file.
This server implements both MCP transports, selected via MCP_TRANSPORT, because different clients require different ones:
Client | Transport it needs | Works with this server? |
Claude Desktop, Claude Code | stdio (spawns a local process) | ✅ |
Cursor | stdio (spawns a local process, same | ✅ |
ChatGPT (Developer Mode / custom connectors) | Remote Streamable HTTP or SSE over HTTPS — cannot spawn local stdio commands | ✅ |
Any other MCP client | stdio or Streamable HTTP | ✅ pick whichever transport it speaks |
These clients spawn the server as a local subprocess and talk JSON-RPC over its stdin/stdout — no networking involved. Add this to your client's MCP config (claude_desktop_config.json for Claude Desktop, .cursor/mcp.json for Cursor — the shape is identical):
{
"mcpServers": {
"neuralverge": {
"command": "node",
"args": ["/absolute/path/to/MCP/dist/index.js"],
"env": {
"NEURALVERGE_API_KEY": "your_api_key_here"
}
}
}
}ChatGPT's MCP connectors only accept remote servers over Streamable HTTP or SSE — they cannot launch a local node/npx process the way Claude Desktop and Cursor do. To use this server from ChatGPT, run it in HTTP mode and make it reachable over HTTPS:
MCP_TRANSPORT=http MCP_HTTP_PORT=8787 MCP_HTTP_AUTH_TOKEN=some_shared_secret \
NEURALVERGE_API_KEY=your_api_key_here node dist/index.jsThis starts a stateless Streamable HTTP server (fresh MCP session per request, no server-side session storage) at http://localhost:8787/mcp, plus a GET /health check. To reach it from ChatGPT you need a public HTTPS URL — either:
deploy it to any Node host (Fly.io, Render, a VPS, a container platform, etc.), or
tunnel your local instance for testing (e.g. ngrok http 8787 or a Cloudflare Tunnel).
Then in ChatGPT: enable Developer Mode (Settings → Connectors → Advanced), add a connector pointing at https://your-host/mcp, and set the Authorization: Bearer <MCP_HTTP_AUTH_TOKEN> header if you set one.
Security note: NEURALVERGE_API_KEY lives on the server and is shared by everyone who can reach the HTTP endpoint — it is not per-ChatGPT-user. Always set MCP_HTTP_AUTH_TOKEN (or put the server behind your own auth) before exposing it publicly; otherwise anyone with the URL can spend your NeuralVerge points.
You can exercise the server with the official MCP Inspector:
NEURALVERGE_API_KEY=your_api_key_here npm run inspectorThe Inspector's "HTTP" connection mode also works against the http transport (point it at http://localhost:8787/mcp), which is a convenient way to sanity-check the ChatGPT-facing path without a real ChatGPT connector.
The NeuralVerge API returns these status codes, which this server surfaces as MCP tool errors with a descriptive message:
Status | Meaning |
400 | Bad Request — invalid body/parameters. Not retryable without fixing the request. |
401 | Unauthorized — missing/invalid/revoked token. Check |
402 | Payment Required — plan or usage limits reached (out of points), or onboarding not finished ( |
404 | Not Found — invalid session id or inaccessible resource. |
429 | Too Many Requests — the request waited 60 s in the queue without a free slot (organization or per-endpoint rate limit). It never ran, so it is safe to retry after an exponential backoff. |
500 | Internal Error — upstream/provider issue. Safe to retry. |
src/
client.ts # thin fetch wrapper: auth header, error mapping
tools.ts # registers one MCP tool per endpoint (JSON schema -> zod)
endpoints.generated.ts # all 342 endpoints, generated from the OpenAPI spec
endpoint-types.ts # types for the generated endpoint list
index.ts # MCP server bootstrap (stdio transport, or Streamable HTTP if MCP_TRANSPORT=http)
scripts/
generate-endpoints.mjs # `npm run generate`: OpenAPI spec -> endpoints.generated.ts + README tool listMIT — see LICENSE.
Get full Alibaba product details by ID or URL: price tiers, MOQ, attributes, variants, and supplier. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product ID or URL. e.g. 1601022319019 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the output contents and the cost model ('Flat 5 points per successful run'), which is genuine behavioral context. However, it omits auth/permission requirements, rate limits, and error behavior for a paid external-API call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences with no filler; the core purpose and content list are front-loaded, and the cost note is appended without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly enumerates the returned fields so the agent knows what it gets back, and it covers the single required input. It is nearly complete for a one-parameter detail tool, missing only usage routing to the search sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter with 100% schema description coverage, so the baseline is 3. The description restates that the product can be an ID or URL, matching the schema without adding syntax or format detail beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Get full Alibaba product details') and enumerates the returned content (price tiers, MOQ, attributes, variants, supplier). The 'by ID or URL' phrasing implicitly distinguishes it from the search sibling, but it never names run_alibaba_product_search, so the differentiation is inferable rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: requiring an ID or URL suggests this is a detail-fetch step that follows a search, but no alternative is named and no when-to-use or when-not-to-use guidance is given. The agent must infer that run_alibaba_product_search is the upstream tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Alibaba products by keyword: price, MOQ, supplier, and certifications. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Max items (up to 250) | |
| keyword | Yes | Search term. e.g. phone case |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose a genuinely useful cost model (1 point per returned record), but omits the result format, how the 250-item cap interacts with the implicit pagination, and any auth/rate-limit context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the core action front-loaded and the cost note appended. Nothing is wasted, though the field list reads as slightly ambiguous output rather than input detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter search with full schema coverage and no output schema, the description is adequate but thin: it hints at returned fields and states the cost, yet omits return shape, ordering, and how results relate to successive search calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, documenting both keyword and count, so the schema already does the heavy lifting. The listed fields (price, MOQ, etc.) are output attributes rather than parameters, so the description adds no syntax or formatting detail beyond the schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb (Search) and resource (Alibaba products) scoped by keyword, and enumerates the attributes surfaced (price, MOQ, supplier, certifications). It distinguishes itself well from most siblings, though it never explicitly contrasts with run_alibaba_product (the singular detail tool).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use, when-not-to-use, or alternative routing guidance. In a catalog with ~250 sibling marketplace tools and a near-identical run_alibaba_product, the description leaves the search-vs-detail decision entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get AliExpress product details by ID: title, price, images, and store. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product ID or URL. e.g. 1005012791281455 | |
| currency | No | Currency. Options: USD = USD, EUR = EUR, GBP = GBP, CAD = CAD, AUD = AUD, RUB = RUB, BRL = BRL, CLP = CLP, JPY = JPY, KRW = KRW, CHF = CHF, SEK = SEK, PLN = PLN, ILS = ILS, NOK = NOK, DKK = DKK, NZD = NZD, MXN = MXN, COP = COP, TRY = TRY, THB = THB, SGD = SGD, MYR = MYR, PHP = PHP, IDR = IDR, INR = INR, VND = VND, HKD = HKD, TWD = TWD, AED = AED, SAR = SAR, CZK = CZK, HUF = HUF, RON = RON, BGN = BGN, UAH = UAH, KZT = KZT, ARS = ARS, EGP = EGP, ZAR = ZAR, CNY = CNY, PEN = PEN | |
| language | No | Content language. Options: ar_MA = ar_MA, de_DE = de_DE, en_US = en_US, es_ES = es_ES, fr_FR = fr_FR, in_ID = in_ID, it_IT = it_IT, iw_IL = iw_IL, ja_JP = ja_JP, ko_KR = ko_KR, nl_NL = nl_NL, pl_PL = pl_PL, pt_BR = pt_BR, ru_RU = ru_RU, th_TH = th_TH, tr_TR = tr_TR, vi_VN = vi_VN |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does add genuinely useful non-schema context — "Flat 5 points per successful run" discloses the cost profile and that billing is per successful run. It says nothing about auth, rate limits, failure behavior, or whether a missing ID errors or returns empty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero waste: the core purpose leads, and the cost disclosure follows. Nothing is redundant with the schema and no filler is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, listing the return fields (title, price, images, store) is a real contribution that tells the agent what it gets back. Together with the cost note, this is close to complete for a simple single-item lookup; only error/edge behavior is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 three parameters, including the product ID/URL format and full enum lists for currency and language. The description adds nothing about currency/language behavior, so baseline 3 applies. Note a small mismatch: the description says "by ID" while the schema also accepts a URL.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Get AliExpress product details") and scopes it to a single item via "by ID," which implicitly separates it from run_aliexpress_product_search. It also enumerates returned fields, making the purpose concrete. However, it never names the sibling search/reviews tools, so differentiation rests on inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase "by ID" implies this is for a single already-known product rather than discovery, which is a usable hint. But there is no explicit when-to-use/when-not guidance and no pointer to run_aliexpress_product_search for the discovery case or run_aliexpress_product_reviews for reviews.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get buyer reviews for an AliExpress product by ID: rating, text, and buyer details. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Review filter. Options: image = With images, additional = Additional feedback, local = Local reviews | |
| product | Yes | Product ID or URL. e.g. 1005012791281455 | |
| currency | No | Currency. Options: USD = USD, EUR = EUR, GBP = GBP, CAD = CAD, AUD = AUD, RUB = RUB, BRL = BRL, CLP = CLP, JPY = JPY, KRW = KRW, CHF = CHF, SEK = SEK, PLN = PLN, ILS = ILS, NOK = NOK, DKK = DKK, NZD = NZD, MXN = MXN, COP = COP, TRY = TRY, THB = THB, SGD = SGD, MYR = MYR, PHP = PHP, IDR = IDR, INR = INR, VND = VND, HKD = HKD, TWD = TWD, AED = AED, SAR = SAR, CZK = CZK, HUF = HUF, RON = RON, BGN = BGN, UAH = UAH, KZT = KZT, ARS = ARS, EGP = EGP, ZAR = ZAR, CNY = CNY, PEN = PEN | |
| language | No | Content language. Options: ar_MA = ar_MA, de_DE = de_DE, en_US = en_US, es_ES = es_ES, fr_FR = fr_FR, in_ID = in_ID, it_IT = it_IT, iw_IL = iw_IL, ja_JP = ja_JP, ko_KR = ko_KR, nl_NL = nl_NL, pl_PL = pl_PL, pt_BR = pt_BR, ru_RU = ru_RU, th_TH = th_TH, tr_TR = tr_TR, vi_VN = vi_VN | |
| max_items | No | Max items (up to 250) | |
| translate | No | Translate to English |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds genuinely useful behavior: the credit cost per record and the shape of returned data. However it omits pagination behavior, rate limits, and whether review coverage is complete or sampled, leaving meaningful gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the purpose and then the return contents and cost. No filler, every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only reviews fetcher with no output schema and complete parameter coverage, the description conveys purpose, return fields, and cost adequately. Pagination and auth expectations are the only notable omissions, which is minor for this tool type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all six parameters (including enum options for filter, currency, language) are already fully documented in the schema. The description adds only 'by ID', which slightly conflicts with the schema's 'Product ID or URL'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get) and resource (buyer reviews) scoped to AliExpress products, plus what is returned (rating, text, buyer details). It is clearly distinguishable from run_aliexpress_product and run_aliexpress_product_search, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied - fetch reviews for a known product - but there is no explicit when-to-use/when-not guidance or mention of alternatives like run_aliexpress_product. The cost note ('1 point per returned record') gives partial decision context but is not a usage rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search AliExpress products by keyword: title, price, and image. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: orders = Orders, price_low_to_high = Price: low to high, price_high_to_low = Price: high to low | |
| choice | No | AliExpress Choice | |
| country | No | Ship-to country. e.g. US | |
| filters | No | Attribute filters. e.g. Comma-separated | |
| keyword | Yes | Search term. e.g. wireless mouse | |
| currency | No | Currency. Options: USD = USD, EUR = EUR, GBP = GBP, CAD = CAD, AUD = AUD, RUB = RUB, BRL = BRL, CLP = CLP, JPY = JPY, KRW = KRW, CHF = CHF, SEK = SEK, PLN = PLN, ILS = ILS, NOK = NOK, DKK = DKK, NZD = NZD, MXN = MXN, COP = COP, TRY = TRY, THB = THB, SGD = SGD, MYR = MYR, PHP = PHP, IDR = IDR, INR = INR, VND = VND, HKD = HKD, TWD = TWD, AED = AED, SAR = SAR, CZK = CZK, HUF = HUF, RON = RON, BGN = BGN, UAH = UAH, KZT = KZT, ARS = ARS, EGP = EGP, ZAR = ZAR, CNY = CNY, PEN = PEN | |
| language | No | Content language. Options: ar_MA = ar_MA, de_DE = de_DE, en_US = en_US, es_ES = es_ES, fr_FR = fr_FR, in_ID = in_ID, it_IT = it_IT, iw_IL = iw_IL, ja_JP = ja_JP, ko_KR = ko_KR, nl_NL = nl_NL, pl_PL = pl_PL, pt_BR = pt_BR, ru_RU = ru_RU, th_TH = th_TH, tr_TR = tr_TR, vi_VN = vi_VN | |
| max_items | No | Max items (up to 250) | |
| max_price | No | Max price | |
| min_price | No | Min price | |
| ship_from | No | Ship-from country. e.g. Any | |
| start_page | No | Starting page | |
| free_shipping | No | Free shipping | |
| local_shipping | No | Local shipping | |
| four_star_and_up | No | 4 stars & up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It usefully discloses a cost of 1 point per returned record and the basic returned fields, but it does not explain pagination behavior, rate limits, or how max_items and start_page interact with billing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences with the core purpose and cost front-loaded. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The described purpose and cost are clear, and the schema fully documents parameters. However, for a 15-parameter search tool with no annotations and no output schema, the description omits pagination behavior, result limits, and selection guidance among sibling search tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 15 parameters are already documented in the input schema. The description adds no parameter-specific semantics beyond naming keyword and returned fields, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: search AliExpress products by keyword. It also says the output includes title, price, and image. It does not explicitly distinguish itself from nearby sibling tools like run_aliexpress_product or run_aliexpress_product_reviews.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a keyword-based search tool but gives no guidance on when to choose it over alternatives, such as run_alibaba_product_search or the AliExpress detail and review tools. It also does not mention pagination, sorting, or filtering strategy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full Amazon product details by ASIN: title, brand, price, images, rating, features, and seller. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| asin | Yes | ASIN. e.g. B0BSHF7WHW | |
| domain | No | Domain. Options: amazon.com = amazon.com, amazon.co.uk = amazon.co.uk, amazon.de = amazon.de, amazon.fr = amazon.fr, amazon.it = amazon.it, amazon.es = amazon.es, amazon.ca = amazon.ca, amazon.co.jp = amazon.co.jp, amazon.com.mx = amazon.com.mx, amazon.com.br = amazon.com.br, amazon.in = amazon.in, amazon.com.au = amazon.com.au, amazon.nl = amazon.nl, amazon.se = amazon.se, amazon.pl = amazon.pl, amazon.com.tr = amazon.com.tr, amazon.ae = amazon.ae, amazon.sa = amazon.sa, amazon.sg = amazon.sg |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses cost ("Flat 5 points per successful run") and enumerates returned data, which substitutes for a missing output schema. It says nothing about rate limits, failure modes, or whether results differ by domain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the capability and followed by the cost note. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Listing returned fields compensates for the absent output schema, so an agent knows what to expect. The remaining gap is the domain parameter: the description never notes that data and pricing are marketplace-specific, which matters for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the ASIN example and the 19-value domain enum are fully documented in the schema. The description adds the ASIN key but gives no meaning for the domain parameter. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb-plus-resource ("Get full Amazon product details") keyed by ASIN, with an explicit enumeration of returned fields. The ASIN-keyed framing implicitly distinguishes it from run_amazon_product_search, but no sibling is named outright.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: "by ASIN" signals you need an identifier in hand, which rules out the search tool by inference. There is no explicit when-to-use/when-not clause or mention of run_amazon_product_offers, run_amazon_seller, or other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all marketplace offers for an Amazon product by ASIN: price, condition, seller, and delivery. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| asin | Yes | ASIN. e.g. B0BSHF7WHW | |
| domain | No | Domain. Options: amazon.com = amazon.com, amazon.co.uk = amazon.co.uk, amazon.de = amazon.de, amazon.fr = amazon.fr, amazon.it = amazon.it, amazon.es = amazon.es, amazon.ca = amazon.ca, amazon.co.jp = amazon.co.jp, amazon.com.mx = amazon.com.mx, amazon.com.br = amazon.com.br, amazon.in = amazon.in, amazon.com.au = amazon.com.au, amazon.nl = amazon.nl, amazon.se = amazon.se, amazon.pl = amazon.pl, amazon.com.tr = amazon.com.tr, amazon.ae = amazon.ae, amazon.sa = amazon.sa, amazon.sg = amazon.sg |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses a billing trait ('Flat 5 points per successful run') and implies a read-only scope via 'Get', but says nothing about pagination, whether 'all' offers are truly complete, rate limits, or auth needs. Partial disclosure earns a middle score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler; the core capability and returned fields are front-loaded, and the cost note is a compact, useful second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read tool with no output schema, the description helpfully enumerates the returned fields (price, condition, seller, delivery), which compensates for the missing output schema. It is slightly incomplete in not acknowledging the domain parameter's effect on which marketplace is queried.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the ASIN and domain parameters are already documented in the schema; baseline is 3. The description mentions the ASIN key but adds no meaning about the multi-domain enum or what changing domain implies for results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get) and resource (all marketplace offers for an Amazon product) plus the identifying key (ASIN) and the fields returned. An agent can distinguish it from run_amazon_product and run_amazon_seller_products, though it does not name those siblings explicitly to reinforce the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description never says when to reach for this tool versus the many adjacent Amazon tools (run_amazon_product, run_amazon_seller_products, run_amazon_product_search). There is no when-to-use, prerequisite, or exclusion guidance; the agent must infer routing from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Amazon and extract product listings (title, URL, price, rating) across paginated results. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term. e.g. wireless mouse | |
| domain | No | Domain. Options: amazon.com = amazon.com, amazon.co.uk = amazon.co.uk, amazon.de = amazon.de, amazon.fr = amazon.fr, amazon.it = amazon.it, amazon.es = amazon.es, amazon.ca = amazon.ca, amazon.co.jp = amazon.co.jp, amazon.com.mx = amazon.com.mx, amazon.com.br = amazon.com.br, amazon.in = amazon.in, amazon.com.au = amazon.com.au, amazon.nl = amazon.nl, amazon.se = amazon.se, amazon.pl = amazon.pl, amazon.com.tr = amazon.com.tr, amazon.ae = amazon.ae, amazon.sa = amazon.sa, amazon.sg = amazon.sg | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses useful behavioral context: pagination, returned fields, and a cost model of '1 point per returned record.' It does not mention read-only safety, permissions, rate limits, or failure behavior, so it is only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is a single, front-loaded sentence with no filler. Every phrase contributes: action, resource, extracted fields, pagination, and cost.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema or annotation coverage, but the description names the key returned fields and mentions pagination and cost. Combined with the fully described input schema, this is sufficient for an agent to call the tool correctly, though it could say more about domain handling or large result sets.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so query, domain, max_items, and start_page are already documented in the schema. The description adds only indirect context through 'paginated results' and the per-record cost, which loosely relates to max_items and start_page but does not explain them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Search Amazon and extract product listings.' It also identifies the returned fields (title, URL, price, rating) and pagination scope, so the agent can distinguish this from non-search Amazon tools. It does not explicitly name sibling alternatives such as run_amazon_product or run_amazon_product_offers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The search framing implies when to use the tool, and the mention of paginated results gives some operational context. However, it does not state when to prefer this over run_amazon_product, run_amazon_product_offers, or other marketplace search tools, nor does it give exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an Amazon seller profile by seller ID: name, rating, business details, and contact info. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Domain. Options: amazon.com = amazon.com, amazon.co.uk = amazon.co.uk, amazon.de = amazon.de, amazon.fr = amazon.fr, amazon.it = amazon.it, amazon.es = amazon.es, amazon.ca = amazon.ca, amazon.co.jp = amazon.co.jp, amazon.com.mx = amazon.com.mx, amazon.com.br = amazon.com.br, amazon.in = amazon.in, amazon.com.au = amazon.com.au, amazon.nl = amazon.nl, amazon.se = amazon.se, amazon.pl = amazon.pl, amazon.com.tr = amazon.com.tr, amazon.ae = amazon.ae, amazon.sa = amazon.sa, amazon.sg = amazon.sg | |
| seller | Yes | Seller ID. e.g. A2L77EE7U53NWQ |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the cost model ('Flat 5 points per successful run'), which is real information beyond the schema, but says nothing about failure modes, auth requirements, or what happens when a seller ID is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler, and the core action plus return fields are front-loaded before the cost note. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter lookup with full schema coverage and no output schema, the description adequately lists the returned fields and discloses cost. It is nearly complete, missing only sibling routing and error/not-found behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters (seller, domain) are fully documented in the schema, so the baseline of 3 applies. The description reinforces that lookup is 'by seller ID' but adds nothing about the domain parameter or ID format beyond the schema example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get an Amazon seller profile by seller ID') and enumerates the returned fields (name, rating, business details, contact info). It implicitly distinguishes itself from run_amazon_seller_products, which is about a seller's listings, but it does not name that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over alternatives such as run_amazon_seller_products or the various other marketplace seller tools. The description only states what it returns, leaving the agent to infer usage context on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List products sold by an Amazon seller's storefront: title, URL, price, rating, and image. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Domain. Options: amazon.com = amazon.com, amazon.co.uk = amazon.co.uk, amazon.de = amazon.de, amazon.fr = amazon.fr, amazon.it = amazon.it, amazon.es = amazon.es, amazon.ca = amazon.ca, amazon.co.jp = amazon.co.jp, amazon.com.mx = amazon.com.mx, amazon.com.br = amazon.com.br, amazon.in = amazon.in, amazon.com.au = amazon.com.au, amazon.nl = amazon.nl, amazon.se = amazon.se, amazon.pl = amazon.pl, amazon.com.tr = amazon.com.tr, amazon.ae = amazon.ae, amazon.sa = amazon.sa, amazon.sg = amazon.sg | |
| seller | Yes | Seller ID. e.g. A2L77EE7U53NWQ | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the returned fields and the cost model ('1 point per returned record'), which is genuinely useful behavioral context, but says nothing about pagination behavior, rate limits, permissions, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler: the scope/return fields come first and the billing note last. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully enumerates the returned fields, and the cost signal covers an otherwise invisible constraint. The only gap is behavioral detail around pagination and result limits, which matters for a 250-item-capped listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (seller, domain enum, max_items, start_page all documented), so the baseline is 3. The description adds no parameter-level meaning (e.g. how seller IDs are obtained, or pagination interaction between max_items and start_page) beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) plus the resource (products sold by an Amazon seller's storefront) and enumerates the returned fields. This distinguishes it in scope from run_amazon_seller (seller profile) and run_amazon_product_search (keyword search), though it never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The scope in the description implies the usage condition (you have a seller ID and want their catalog), but there is no explicit when-to-use, when-not, or pointer to alternatives such as run_amazon_seller or run_amazon_product_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Argentina registry of legal entities (Registro Nacional de Sociedades, IGJ) by CUIT or registry link: name, company type, contract date, legal and fiscal address, activities and last update. 5 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | CUIT or registry URL. e.g. 30-54668997-9 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose a genuinely useful behavioral trait — the cost of '5 point per returned record' — and enumerates the response fields, but says nothing about authorization needs, rate limits, or what happens when the CUIT/URL is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the verb, source registry, and accepted identifier before listing return fields. The field enumeration is long but earns its place because there is no output schema; nothing is redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by naming the returned fields (name, company type, contract date, addresses, activities, last update) and the per-record cost. It is close to complete for a one-parameter lookup, missing only failure/empty-result behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter and schema description coverage is 100%, so the schema already documents the CUIT/registry-URL input and even supplies the example 30-54668997-9. The description restates the accepted identifier forms but adds no format, validation, or normalization detail beyond the schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb and resource: 'Get one company from the Argentina registry of legal entities (Registro Nacional de Sociedades, IGJ) by CUIT or registry link,' with the returned fields enumerated. The singular lookup-by-identifier framing implicitly separates it from run_ar_companies_search, but the sibling is never named, so differentiation is left partly to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the agent can infer this is the single-record lookup used when it already has a CUIT or registry URL. There is no explicit when-to-use/when-not guidance and no mention of run_ar_companies_search as the alternative for name-based lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Argentina registry of legal entities (Registro Nacional de Sociedades, IGJ) by company name or CUIT: name, CUIT, company type, address, main activity and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Company name. e.g. ypf | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds genuinely useful behavioral context ('1 point per returned record' discloses cost, and it enumerates returned fields), but says nothing about auth requirements, rate limits, or how start_page/max_items interact with pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences, front-loaded with the registry scope and followed by the return fields and cost. Every clause carries information; only the parenthetical acronym list is slightly heavy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no annotations and no output schema, the description compensates well by enumerating returned fields and disclosing per-record cost. The remaining gap is sibling differentiation from run_ar_companies and pagination semantics, which is a modest omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all four parameters; baseline is 3. The description does add one useful fact beyond the schema — that keyword accepts a CUIT, not just a company name (the schema only says 'Company name') — but it adds nothing about status, max_items, or start_page.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (search) and resource (Argentina registry of legal entities, Registro Nacional de Sociedades, IGJ) and lists the returned fields, so the agent knows exactly what it does. It does not, however, differentiate from the sibling run_ar_companies (the non-search lookup variant), leaving the sibling choice ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the searchable keys ('by company name or CUIT'), which implies usage, but gives no explicit when-to-use vs the run_ar_companies sibling and no when-not guidance. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Austria registry (Firmenbuch) by registration number (FN) or registry URL: name, status, legal form, address, previous names and the paid extracts offered. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Registration number (FN) or registry URL. e.g. 56247t |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it partly meets it: it enumerates the returned fields (name, status, legal form, address, previous names, paid extracts) and discloses the cost model ('Flat 5 points per successful run'). It says nothing about authentication, error behavior for an invalid FN, or rate limits, so the behavioral picture is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense, front-loaded sentence covering identifier, source, and returned fields, followed by a short pricing note. Nothing is padded. The return-field list is slightly long but is the main value-add given there is no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup with no output schema and no annotations, the description compensates well by enumerating the response fields and stating the point cost. It is essentially complete for correct invocation; only failure/permission behavior is left unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'company' parameter already documents both the FN format and the example token, so the description cannot add much. Its 'registration number (FN) or registry URL' phrasing restates the schema rather than extending it. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get one company), the exact resource (Austria registry / Firmenbuch), and the accepted identifiers (FN or registry URL), plus an enumerated field list. It clearly reads as a single-entity lookup, which implicitly separates it from the broad family of company tools. The one gap versus a 5 is that the obvious sibling run_at_companies_search is never named, so the routing distinction is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the input contract: an agent should reach for this when it already holds an FN or registry URL, and use a search variant when it only has a name. However, no alternative is named and no when-not condition is given, so the guidance is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Austria company registry (Firmenbuch) by company name or FN: name, registration number, status, seat and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Company name. e.g. red bull | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the credit cost ('1 point per returned record'), which is not in the schema, but says nothing about pagination behavior (despite start_page/max_items params), auth requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence describing the search plus a short cost note; no filler. Slightly dense with the returned-field list, but every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema and no annotations, the description conveys the source, key inputs, credit cost, and the shape of the result (name, number, status, seat, link). Missing only guidance on paginating through large result sets and the distinction from run_at_companies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are documented, establishing the baseline of 3. The description adds only a small clarification that the keyword can be a company name or an 'FN' (registration number), which the schema's keyword field does not mention; this is marginal value over structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (Austria company registry / Firmenbuch) and lists the returned fields (name, registration number, status, seat, link). It identifies the country scope, which separates it from the dozens of other country registry tools, but does not differentiate it from its own sibling run_at_companies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description never says when to use this search tool versus the plain run_at_companies lookup, nor does it state prerequisites or the conditions under which results are empty. Usage must be inferred entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Australia registry (ASIC / ABN) by registration number or registry URL: name, status, registration date, address and legal form. Flat 10 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Registration number or registry URL. e.g. 88000014675 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully enumerates the returned fields and discloses the cost model ('Flat 10 points per successful run'), but says nothing about authorization requirements, failure behavior for invalid IDs, or whether results are cached/live.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and resource, followed by the output fields and pricing. Compact and free of padding, though the field list and cost note could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup with no output schema, the description compensates well by listing the returned fields (name, status, registration date, address, legal form). The main remaining gap is the absence of guidance on the search sibling and error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single `company` parameter is already documented with an example in the schema. The description restates the same accepted formats without adding syntax, formatting, or validation detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('Get one company from the Australia registry (ASIC / ABN)') and scopes it to a single record retrieved by registration number or registry URL, which implicitly separates it from the plural run_au_companies_search sibling. It stops short of naming that alternative explicitly, so the differentiation is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It tells the agent the required identifier (registration number or registry URL), which implies you need a known ID rather than a name, but it never says when to choose this over run_au_companies_search or what to do when you only have a company name. Usage is implied, not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Australia company registry (ASIC / ABN) by company name: name, registration number, status, address and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Company name. e.g. woolworths | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses the billing model ('1 point per returned record'), which is real behavioral value, but says nothing about auth, rate limits, or what happens with zero matches.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence that front-loads the action and scope. Efficient, though the trailing field list and cost note make it slightly dense rather than optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully enumerates the return fields (name, registration number, status, address, link), which compensates for the missing output schema. Pagination semantics are left to the schema, but overall it is complete enough to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 keyword, status, max_items and start_page. The description adds no syntax or format detail beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (Australia company registry / ASIC / ABN), plus the fields returned. 'By company name' hints at how it differs from the run_au_companies sibling, but it never explicitly contrasts with it, so an agent must infer the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the phrase 'by company name' suggests you supply a name to search. There is no explicit when-to-use statement, no exclusions, and no reference to the many sibling company-registry tools (run_au_companies, run_nz_companies_search, etc.).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Avito category tree: departments and sub-categories with id, name, alias (URL slug for the category filter), parent id, level and browse URL. 5 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses cost ('5 point per returned record') and the shape of returned records, but does not state read-only safety, authentication needs, rate limits, or whether the full tree is returned in one call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with no filler. The core purpose and return fields are front-loaded, and the cost note is brief and relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless read tool with no output schema, the description adequately covers the returned tree structure, field names, and cost. It could still mention whether the entire tree is returned or whether any pagination/depth limit applies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero input parameters, so the baseline is 4. There are no parameter semantics to clarify, and the description correctly does not invent any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('Avito category tree'), then enumerates the returned fields (id, name, alias, parent id, level, browse URL). This clearly distinguishes it from sibling Avito tools like run_avito_items and run_avito_items_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use statement or comparison to alternatives. However, the parenthetical '(URL slug for the category filter)' implies the tree is used to discover category filters for other Avito search tools, making usage inferable but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a full Avito listing by id or URL: title, price (RUB), description, specification params, category and breadcrumbs, address and coordinates, view counts, posting time, photos and seller. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| item | Yes | Listing ID or URL. e.g. 8132133298 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it enumerates the returned payload (price in RUB, coordinates, view counts, seller) and discloses a cost model ('Flat 5 points per successful run'). It does not mention auth or rate limits, but for a read-only fetch the field list plus cost note is strong disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and resource, followed by a compact enumeration of returned fields and a one-clause cost note. The field list is long but each item is meaningful, and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must convey return values, and it does so thoroughly via the field enumeration. Missing only usage routing and any note on failure modes for invalid ids, which are minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'item' param already documents 'Listing ID or URL. e.g. 8132133298'. The description's 'by id or URL' merely echoes the schema, so baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get) and resource (a full Avito listing) and pins the input mode ('by id or URL'). The phrase 'full listing' implicitly distinguishes it from run_avito_items_search, which returns lists rather than one detailed item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'By id or URL' implies the tool needs a concrete identifier, which is useful context, but the description never states when to prefer it over run_avito_items_search or where those ids come from. Usage is inferred rather than spelled out, and no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Avito listings by keyword with region, category, price range, sort, seller type, Avito Delivery and attribute filters. Returns title, price, location, coordinates, image and seller for each listing. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: default = Default, price_asc = Price: low to high, price_desc = Price: high to low, date = Newest | |
| params | No | Attribute filters (JSON). e.g. {"110395": "431241"} | |
| region | No | Region. e.g. all, moskva, sankt-peterburg | |
| keyword | Yes | Search term. e.g. iphone 13 | |
| category | No | Category. e.g. telefony, avtomobili | |
| delivery | No | Avito Delivery | |
| max_items | No | Max items (up to 150) | |
| price_max | No | Max price (RUB) | |
| price_min | No | Min price (RUB) | |
| start_page | No | Starting page | |
| seller_type | No | Seller type. Options: any = Any, private = Private, company = Company |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does reasonably well: it discloses the returned fields (title, price, location, coordinates, image, seller) and the cost model ('1 point per returned record'). It omits auth/permission requirements and rate/limit behavior, but the return and cost disclosure is meaningful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, no filler: purpose + filters, then return fields, then cost. The most decision-relevant information (keyword search, filters) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description usefully enumerates return fields and the point cost. Pagination semantics (start_page/max_items behavior, whether pages are 1-indexed and how many results per page) are not explained, which is a minor remaining gap for a paginated search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 11 parameters with enums and examples. The description lists the same filter categories (region, category, price range, sort, seller type, delivery, attributes) without adding syntax or format detail beyond the schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search Avito listings by keyword') and enumerates the filter dimensions it supports. It is clearly distinguishable from siblings like run_avito_sellers or run_avito_categories by the keyword-search framing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The list of filters implies the tool's intended use, but there is no explicit when-to-use guidance, no exclusions, and no comparison to alternatives such as run_avito_items (item detail) or run_avito_categories. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an Avito seller (brand page) by slug or URL: name, type, rating, review count, followers, active listing count, registration date and badges. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| seller | Yes | Brand slug or URL. e.g. steve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the pricing model ('Flat 5 points per successful run', implying failures are not charged) and telegraphs a read-only operation via 'Get', but says nothing about authentication, rate limits, or error behaviour beyond the success qualifier.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: purpose and returned fields first, cost second. No filler, no restatement of the tool name, and the most decision-relevant information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema and no annotations, the description compensates well by listing the returned fields and disclosing cost. Only the lack of when-to-use routing against Avito siblings and any error/permission context keeps it short of full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is already documented as 'Brand slug or URL. e.g. steve'. The description's 'by slug or URL' merely restates the schema, adding no new syntax or format detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Get an Avito seller (brand page)') and then enumerates exactly what is returned – name, type, rating, review count, followers, listings, registration date, badges. It is clearly distinguishable from Avito siblings such as run_avito_items_search or run_avito_categories without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by slug or URL' implies the caller must already possess a seller identifier, so the tool is for lookups rather than discovery – but no explicit when-to-use guidance or named alternative (e.g. run_avito_items_search for locating sellers) is given. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Belgium registry (KBO/BCE) by enterprise number or registry URL: name, status, start date, address, legal form, activities, directors, contact details and establishment units. 10 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Enterprise number or registry URL. e.g. 0202.239.951 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden. It usefully discloses cost ('10 point per returned record') and the enumerated return fields, and the verb 'Get' implies a read-only lookup. It does not state auth requirements, rate limits, not-found behavior, or explicitly confirm no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence names the source, the key, and the returned fields, followed by a short cost note. Every clause earns its place; the field enumeration is slightly long but is the only place return content is documented.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must describe the response — and it does, enumerating name, status, start date, address, legal form, activities, directors, contact details and establishment units. Combined with the cost disclosure this is nearly complete for a single-record lookup; only auth/error behavior is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — the single 'company' parameter is already documented with the same 'Enterprise number or registry URL' wording and an example (0202.239.951). The description restates that meaning without adding format or validation detail, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: fetch ONE company from the Belgium registry (KBO/BCE), keyed by enterprise number or URL. The 'one company' framing implicitly separates it from the run_be_companies_search sibling, but it never names that sibling explicitly, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the input ('by enterprise number or registry URL'), so an agent can infer this is a detail-lookup rather than a discovery tool. However there is no explicit when-to-use statement, no pointer to run_be_companies_search for name-based discovery, and no prerequisites such as where the identifier comes from.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Belgium company registry (KBO/BCE) by company name: name, enterprise number, status, address and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Company name. e.g. proximus | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses the billing model ("1 point per returned record"), which is real behavioral context, but says nothing about pagination behavior, result limits, auth, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the registry, search key, and return fields come first, followed by the cost. No filler and everything is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by enumerating the returned fields, and it adds the cost model. It stops short of mentioning pagination semantics for start_page/max_items, the one remaining gap for a 4-parameter search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so keyword, status, max_items, and start_page are already documented in the schema. The description adds only that search is by company name, which is redundant with the schema's keyword description, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search) and resource (Belgium company registry KBO/BCE), plus the returned fields (name, enterprise number, status, address, link). It implicitly distinguishes itself from the dozens of other run_*_companies_search siblings by naming the country, though it never explicitly contrasts with run_be_companies or other registries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is only implied by the country reference; there is no explicit when-to-use guidance and no contrast drawn against the non-search sibling run_be_companies or other country registries. An agent can infer the fit from the name, but nothing is spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one startup from BetaList by slug or URL: name, tagline, description, makers, topics, launch date, screenshots and similar startups. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| startup | Yes | Startup slug or BetaList URL. e.g. iconscove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the returned data fields and a flat 5-point cost per successful run, but it says nothing about failure behavior, authentication, rate limits, or what happens if the slug/URL is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that identifies the resource, input format, returned fields, and cost. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter retrieval tool with no output schema and no annotations, the description is largely complete: it names the source, input, returned fields, and cost. It could be stronger by mentioning expected failure cases or pointing to the search sibling when only a name is known.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single parameter is already well documented in the schema with an example. The description reinforces that the parameter accepts a slug or URL, but it adds no format details or constraints beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: get one startup from BetaList by slug or URL. It also enumerates the returned fields, making it clear this is a single-startup detail lookup rather than a search or listing tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by slug or URL' implies the tool is for fetching a known startup, but it does not explicitly state when to use this versus sibling tools like run_betalist_startups_search or run_betalist_startups_latest. Usage is inferable but not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The newest startups on BetaList, newest first: name, tagline, logo and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the cost model ('1 point per returned record') and enumerates returned fields, but says nothing about pagination behavior (only implied by start_page), rate limits, or auth. It adds real value beyond structure but leaves notable behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence that front-loads the resource and ordering, then lists return fields and cost. Every clause earns its place, though the field enumeration is slightly dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with no output schema, the description compensates by naming the returned fields (name, tagline, logo, link) and the cost, and the schema fully documents the two parameters. The missing piece is routing guidance against sibling tools, which keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (max_items, start_page) are already documented in the schema. The description only tangentially touches cost ('1 point per returned record') and adds no new semantics for the parameters themselves. Baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (newest startups on BetaList) with ordering (newest first) and the returned fields, so an agent knows exactly what it fetches. It does not explicitly differentiate itself from siblings like run_betalist_startups or run_betalist_startups_search, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance or named alternative. The phrase 'newest first' weakly implies chronological browsing versus searching, but the description never tells the agent when to pick this over run_betalist_startups_search or run_betalist_startups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search BetaList startups by keyword: name, tagline, logo and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Keyword. e.g. ai | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it discloses two useful traits: the returned fields (name, tagline, logo, link) and the cost model ('1 point per returned record'). That is real added context, but it says nothing about pagination behaviour for start_page, empty results, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler. The cost sentence earns its place by warning about per-record charges, though the returned-field list could have been deferred to an output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description does cover the return fields and cost, which are the two things structured data cannot supply here. However, it omits pagination semantics despite a start_page parameter and gives no sibling routing, leaving gaps for a search tool in a crowded family.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with keyword, max_items (up to 250) and start_page all documented in the schema, so the baseline is 3. The description lists output fields rather than parameter meaning and adds nothing beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search BetaList startups by keyword') and lists the returned fields, so the agent knows exactly what the tool does. It fails to distinguish itself from the close siblings run_betalist_startups, run_betalist_startups_latest and run_betalist_topics_startups, which is the only thing keeping it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance and no mention of the alternatives, despite several BetaList siblings that overlap heavily. The keyword-search nature is implied by the name, but the agent gets no rule for choosing this over run_betalist_startups_latest or run_betalist_topics_startups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Startups of one BetaList topic (slug like generative-ai, category/topic, or a BetaList topic URL): name, tagline, logo and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Topic slug or URL. e.g. generative-ai | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses a cost signal ("1 point per returned record") and enumerates the returned fields, which is more than nothing. However, it says nothing about pagination behavior despite start_page/max_items, rate limits, or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence front-loads the verb and resource, then lists the returned fields and the cost note. No filler or repetition; appropriately sized for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by enumerating returned fields (name, tagline, logo, link). Combined with 100% schema coverage on inputs, an agent has enough to call it correctly. The only missing piece is how it relates to sibling topic/startup tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters including the topic example and the 250-item cap. The description adds mild value by clarifying the topic can be a slug, a category/topic, or a BetaList URL, but mostly restates the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: retrieve startups belonging to one BetaList topic, and even names the return fields (name, tagline, logo, link). It is clear what the tool does, but it never distinguishes itself from siblings like run_betalist_startups, run_betalist_startups_latest, or run_betalist_startups_search, leaving ambiguous which one to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (fetch startups for a single topic) but gives no explicit when-to-use guidance, no exclusions, and never names the alternate BetaList tools. With three near-identical siblings in the list, the absence of routing guidance is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Bulgaria registry (Commercial Register) by UIC (ЕИК) or registry link: name, status, first registration date, address and contacts, legal form, activity, capital and shares, representatives and board, procuracy, trade-undertaking transfers, mergers, predecessors/successors, liquidation, beneficial owners (NPLE), registrar instructions and court case files. 15 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | UIC (ЕИК) or registry URL. e.g. 831902088 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does disclose a genuine behavioral trait: the cost ('15 point per returned record'), which is material for an agent budgeting calls. It also enumerates the returned data surface. It stops short of stating error behavior, whether missing UICs fail, or any auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and identifier type before the long enumeration. The 18-item field list is dense and unsectioned, but since no output schema exists, that enumeration largely earns its place by communicating the record's shape.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates well by enumerating the returned fields, and it discloses cost. For a single-parameter lookup it is nearly complete; only the absence of edge-case or sibling-routing guidance keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is fully documented with an example, so the baseline is 3. The description's 'by UIC (ЕИК) or registry link' restates the schema rather than adding new meaning about accepted formats or validation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Get one company from the Bulgaria registry (Commercial Register)'. The singular 'one company' implicitly separates it from the many *_companies_search siblings, and the country/jurisdiction is unambiguous. An agent can identify the correct tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'one company' implies a single-record lookup rather than a search, which gives implied usage. However, it never explicitly states when to use this versus run_bg_companies_search, nor any prerequisites (e.g., you must already have a UIC or URL). Guidance is inferable but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Bulgaria company registry (Commercial Register) by company name or UIC: name, UIC (ЕИК), legal form and card link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Company name. e.g. sopharma | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the cost model ('1 point per returned record'), which an agent needs for budgeting, but says nothing about permissions, rate limits, or result ordering. As a read-only search this is a modest gap rather than a serious one.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence plus a short field-list fragment; nothing is padded. The cost note is compact. It is efficiently sized for the amount of information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description correctly compensates by enumerating the returned fields (name, UIC, legal form, card link). For a 3-parameter read-only search with no annotations, this covers most of what an agent needs, though pagination behavior across start_page/max_items is left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so keyword, max_items (cap 250) and start_page are already documented. The description adds only that the keyword may be a name or a UIC, which is marginal new meaning; baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) plus the exact resource (Bulgaria company registry / Commercial Register) and the two query modes (company name or UIC), and even lists the returned fields. It is clear on its own, but it never differentiates itself from the closely named sibling run_bg_companies or from run_bg_company_filings, so an agent must infer which to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'search by company name or UIC' implies the intended use, but there is no explicit when-to-use, when-not-to-use, or named alternative among the many country-search and filing siblings. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the announced acts of a Bulgaria company (Commercial Register) by UIC (ЕИК) or registry URL, newest first: announcement date, act type, title and document link (annual reports, notices, reports, current articles). 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | UIC (ЕИК) or registry URL. e.g. 831902088 | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it discloses useful traits beyond structured fields: result ordering ('newest first'), the exact record shape returned, and a cost signal ('1 point per returned record'). It omits whether the call is read-only and how pagination interacts with start_page/max_items, which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the identifying scope (Bulgaria, Commercial Register, UIC/URL), then the ordering and returned fields, then the cost note. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-output-schema, no-annotation read tool, the description supplies the return fields, sort order, accepted identifiers, and cost, which is most of what an agent needs. It does not describe pagination semantics or the granularity of the 'document link', leaving a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so company/max_items/start_page are already documented in the schema; the description restates the UIC/registry-URL input but adds no format or constraint detail beyond it. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and resource ('announced acts of a Bulgaria company (Commercial Register)'), and enumerates the fields returned (announcement date, act type, title, document link). It clearly differs from run_bg_companies/run_bg_companies_search by targeting filings rather than company records, though it never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the resource ('announced acts ... by UIC or registry URL'), so an agent can infer this is the filings lookup for a known Bulgarian company. However, there is no explicit when-to-use vs run_bg_companies or the other *_company_filings tools, and no mention of prerequisites or when it is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Brazil registry (CNPJ / Receita Federal) by registration number or registry URL: name, status, registration date, address and legal form. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Registration number or registry URL. e.g. 33000167000101 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses the return fields and the cost model ("Flat 5 points per successful run"), which is real behavioral context, but says nothing about auth/prerequisite requirements, error behavior, or rate limits for a call producing one legal record.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short clauses, front-loaded with purpose and identifier format before the cost note; nothing is redundant. Tight and readable, though the trailing cost sentence is tangential to selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup with full schema coverage and no output schema, the description compensates by listing the returned fields (name, status, registration date, address, legal form) and the pricing rule. Only auth/prerequisite details and failure behavior are missing, which is minor at this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents the single parameter ("Registration number or registry URL. e.g. 33000167000101"). The description merely restates the same accepted input forms without adding format details or validation guidance, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: "Get one company from the Brazil registry (CNPJ / Receita Federal) by registration number or registry URL", plus an enumeration of returned fields. The word "one" implicitly signals a single-entity lookup, but it never names run_br_companies_search, the obvious sibling, so true sibling differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase "by registration number or registry URL" implies the tool is for looking up a single already-known company, which is usable guidance. However there is no explicit when-to-use vs run_br_companies_search or any when-not/precondition statement, leaving the choice between lookups to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Brazil company registry (CNPJ / Receita Federal data) by company name: name, CNPJ, status and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Company name. e.g. petrobras | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses the cost model ('1 point per returned record') and lists the returned fields, but omits permission/auth requirements, rate limits, and pagination behavior for a tool whose schema exposes start_page and max_items.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the core purpose front-loaded and the cost note appended. No filler or redundancy; efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description responsibly enumerates the return fields (name, CNPJ, status, link) and notes the point cost. It is largely complete for a search tool, with only minor gaps around pagination and access requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 keyword, status, max_items, and start_page. The description only echoes that search is by company name and adds no format or syntax detail beyond what the schema provides, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search), resource (Brazil company registry / CNPJ / Receita Federal data), and enumerates the returned fields (name, CNPJ, status, link). It clearly identifies itself as the name-based search for Brazilian companies, though it does not explicitly distinguish itself from the sibling run_br_companies (the non-search variant).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by company name' implies how to invoke it, and the cost note hints at consumption behavior, but there is no explicit when-to-use/when-not guidance nor any reference to alternatives such as run_br_companies. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one federal corporation from the Corporations Canada registry by corporation number or registry link: name, status, incorporation date, registered office address, governing legislation, directors, individuals with significant control, annual filings and name history. 5 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Corporation number or registry URL. e.g. 426160-7 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden; it usefully discloses the per-record cost ('5 point per returned record') and enumerates the payload contents (directors, significant-control individuals, filings, name history), which tells the agent this is a heavyweight single-record fetch. It still omits permission/auth needs and behavior on an unknown corporation number, keeping it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with verb, resource and lookup key, followed by the returned-field list and cost. The field enumeration is long but earns its place because no output schema exists; a small amount of trimming would still be possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the explicit list of returned fields is the right compensation, and the cost note covers a factor an agent must weigh. Missing pieces are minor: how to obtain the identifier in the first place and what happens on a not-found lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter, and the schema already documents it at 100% coverage, including the same 'e.g. 426160-7' format example. The description restates the accepted key types but adds no new syntax or validation detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get one federal corporation'), the exact registry (Corporations Canada), and the lookup key (corporation number or registry link). The 'one ... by identifier' framing cleanly separates it from the sibling run_ca_companies_search, which is the list/search counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent what input to supply (corporation number or registry link), which implies when to reach for it, but it never states prerequisites (e.g. 'use run_ca_companies_search first to obtain a corporation number') or when not to use it. Usage is inferable rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search federal corporations in the Corporations Canada registry by name, corporation number or business number: name, corporation number, status, business number and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Corporation name. e.g. Shopify | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses a cost model (1 point per returned record) and lists return fields, but omits other behavioral traits like rate limits, pagination behavior, and search matching semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with purpose front-loaded. The colon list of return fields is slightly dense but overall the description is concise and every sentence contributes relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description lists the returned fields (name, corporation number, status, business number, link), which is helpful. It does not explain pagination behavior despite start_page and max_items parameters, but the schema covers those, so the description is largely complete for a simple search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by indicating that the keyword parameter accepts not just corporation name but also corporation number or business number, which the schema's keyword description ('Corporation name') does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (federal corporations in the Corporations Canada registry), and clarifies searchable fields. It does not explicitly differentiate from sibling tools like run_ca_companies or run_ca_company_filings, so it falls just short of the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions the fields that can be searched (name, corporation number, business number), but provides no guidance on when to use this tool versus related alternatives such as run_ca_companies. No exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Certificates and filings of one federal corporation in the Corporations Canada registry: date, type and amendment details. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Corporation number or registry URL. e.g. 426160-7 | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the credit cost ('1 point per returned record') and the return fields, but says nothing about read-only nature, pagination beyond the schema hints, or auth requirements. Partial but not rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler, and the resource scope is front-loaded before the return fields and cost. Efficient, though the credit-cost sentence could be more integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-param read tool with no annotations or output schema, the description compensates reasonably by enumerating the returned fields (date, type, amendment details) and the per-record cost. Only minor gaps around pagination behavior and permissions remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 company, max_items, and start_page. The description adds no format or syntax detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (certificates and filings of one federal corporation in the Corporations Canada registry) and the fields returned (date, type, amendment details). It clearly distinguishes itself from run_ca_companies / run_ca_companies_search by being about filings of a single corporation, though it doesn't name the siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'one federal corporation' and the singular 'company' input, but there is no explicit when-to-use guidance or comparison to the sibling companies/search tools. An agent can infer the intent but gets no routing help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Capterra software categories: name, alias, and canonical URL. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose pricing behavior ('Flat 5 points per successful run'), which is real value beyond the schema, but says nothing about pagination, completeness of the category list, or error behavior on a failed run.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero waste, with the resource and returned fields front-loaded and the cost note appended. Nothing to trim.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description steps in to name the returned fields (name, alias, canonical URL) plus the cost, which is what an agent needs for a zero-parameter listing call. Minor gaps remain around pagination and whether the list is exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline of 4 applies; there is no parameter semantics to document and the description correctly avoids inventing any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List Capterra software categories') and even names the returned fields (name, alias, canonical URL). An agent can distinguish it from Capterra siblings like run_capterra_category_products or run_capterra_products_search, though the description never explicitly contrasts with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites, and no mention of the obvious alternative (run_capterra_category_products) for drilling into a category. The catalog-enumeration use case is only implied by the noun 'categories', not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Capterra products within a software category, ranked as Capterra ranks them. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Category alias or URL. e.g. customer-relationship-management-software | |
| max_items | No | Max items (up to 500) |
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 usefully discloses that results are ranked as Capterra ranks them and that billing costs 1 point per returned record, but it omits authentication, rate limits, pagination, and side-effect details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences with no waste. The purpose and scope are front-loaded, followed by the cost behavior, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with a fully described schema and no output schema, the description covers the core purpose and ranking/cost behavior. It still leaves return structure, pagination, and operational constraints unspecified, so it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description implies the category input but adds no syntax, format, or constraint details beyond what the schema already provides for category and max_items.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List Capterra products') with a clear scope ('within a software category') and ranking behavior. It is distinguishable from siblings like run_capterra_products_search and run_capterra_categories by scope, though it does not name an alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: the tool is for retrieving products when a Capterra category is known. There is no explicit when-to-use, when-not-to-use, or alternative sibling guidance, which keeps this at the minimum viable level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full Capterra product details by id or URL: vendor, pricing, ratings, and features. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product id or URL. e.g. 176586 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden; it does disclose a real behavioral trait — a flat cost of 5 points per successful run, which helps an agent budget calls. It says nothing about rate limits, authentication, or failure behavior, and 'successful run' billing implies failed lookups are free but this is left implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler: the lookup and its payload come first, and the pricing note follows. Nothing is redundant and the front-loading is exactly what an agent scanning tool lists benefits from.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully enumerates the return payload (vendor, pricing, ratings, features), and the single required parameter is fully covered by the schema. The only shortfall is the absent routing guidance relative to sibling Capterra tools, which is a usage gap rather than a completeness-of-call gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'product' parameter already documents that it accepts an id or URL with the example 176586. The description restates 'by id or URL' without adding accepted formats, URL normalization rules, or error behavior for malformed input, so it does not meaningfully exceed the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get) and resource (Capterra product details) plus the key the agent supplies (id or URL) and enumerates the returned fields (vendor, pricing, ratings, features). This implicitly distinguishes it from run_capterra_products_search and run_capterra_products_reviews, which deal with sets and reviews rather than a single full record, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description never says when to reach for this tool versus run_capterra_products_search (discovery) or run_capterra_products_reviews. There is no statement of prerequisites such as needing a valid Capterra product id/URL from a prior search, so the agent must infer the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get user reviews for a Capterra product by id or URL: rating, pros/cons, and author. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product id or URL. e.g. 176586 | |
| max_items | No | Max items (up to 500) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does add two pieces of value beyond the schema: the shape of the returned data and the cost model ('1 point per returned record'), which is a useful non-obvious constraint. It says nothing about pagination behavior, result ordering, or whether reviews are sampled versus complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence plus a short pricing clause; no filler or repetition. It could be marginally tighter, but every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, no-output-schema tool the description covers the essentials (what it returns, cost per record) and the schema covers the inputs. It omits pagination/limit behavior and any indication of review coverage, so it is adequate but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: 'product' already documents id-or-URL with an example (176586) and 'max_items' documents the 1–500 bound. The description only restates 'by id or URL' and adds no syntax, format, or edge-case detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get user reviews for a Capterra product') and enumerates the returned fields (rating, pros/cons, author), which implicitly separates it from run_capterra_product and run_capterra_products_search. It stops short of explicitly naming a sibling to disambiguate, so it is clear but not maximally differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the sibling review tools (e.g. run_producthunt_products_reviews, run_gartner_product) or the Capterra product/search tools. No prerequisites or exclusions are given, leaving the agent to infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Capterra software products by keyword: name, rating, review count, and image. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term. e.g. crm software | |
| max_items | No | Max items (up to 250) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the credit cost ('1 point per returned record'), which is real context beyond structured data, but says nothing about pagination, return format, or auth/permission requirements for a search operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence that front-loads the action, the resource, the returned fields, and the cost. Every clause earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description does well to name the returned fields and the per-record cost, but it omits pagination/limit behavior and any note on result ordering or filtering scope, leaving the agent with a partially complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both query and max_items are fully documented in the schema; the description adds only the informal 'by keyword' framing and nothing about max_items or the 250 cap. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (Capterra software products) and adds the returned fields (name, rating, review count, image), so an agent can distinguish it from generic search tools. It does not, however, differentiate from the nearby run_capterra_category_products or run_capterra_products_reviews siblings, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by keyword' implies the input mode but there is no explicit when-to-use guidance, no exclusions, and no routing to alternatives such as run_capterra_product (single product) or run_capterra_category_products (category-scoped listing). An agent must infer when this is the right entry point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Colombia registry (RUES, Registro Mercantil) by NIT or registry URL: name, status, registration date, address, legal form, economic activity, legal representation and establishments. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | NIT or registry URL. e.g. 899999068-1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the cost model ('Flat 5 points per successful run'), which is real behavioral context beyond the schema, but it omits auth/permission requirements, rate limits, and error behavior for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and source registry, with no filler. The enumerated field list is somewhat long but earns its place as the only disclosure of return values, since no output schema exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the field enumeration supplies return-value context, and the identifier plus registry are clearly stated for a one-parameter lookup. Remaining gaps (auth requirements, failure behavior) are modest given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter already documents 'NIT or registry URL. e.g. 899999068-1'. The description merely restates the accepted identifier types without adding format or validation detail, so the schema does the heavy lifting (baseline 3).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get) and resource (one company from the Colombia RUES/Registro Mercantil registry) and enumerates the returned fields, making the scope concrete. It does not explicitly name or contrast with the run_co_companies_search sibling, so sibling differentiation is left to inference from 'one company'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by NIT or registry URL' implies how to invoke the tool and the identifier types it accepts, giving some usage context. However, there is no explicit statement of when to prefer this single-company lookup over run_co_companies_search, and no exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Colombia company registry (RUES, Registro Mercantil) by name: name, NIT, status, chamber of commerce, category and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Company name. e.g. ecopetrol | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full disclosure burden. It does add genuinely useful non-schema context: the '1 point per returned record' cost model, which the agent cannot learn anywhere else. However, it is silent on pagination behavior, rate limits, auth requirements, or what a failed/empty search looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the registry identity and query dimension front-loaded, followed by the returned fields and cost note. No filler or redundancy, though the field enumeration is slightly list-heavy for a description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema and no annotations, the description compensates reasonably by enumerating returnable fields and disclosing the per-record cost. It is missing only secondary details (pagination semantics, rate limits), which are not essential to selecting and invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 four parameters including the status enum and the max_items/start_page bounds. The description's field list ('name, NIT, status, chamber of commerce, category and link') actually describes return values rather than inputs, so it adds little semantic meaning beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (Search), a specific resource (Colombia company registry / RUES, Registro Mercantil) and the query dimension (by name). It also enumerates the fields returned (name, NIT, status, chamber of commerce, category, link), so the agent knows exactly what this tool yields. It stops short of explicitly distinguishing itself from the sibling run_co_companies (the non-search variant).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by name' implies this is the lookup path when a company name or keyword is known, but there is no explicit when-to-use / when-not-to-use statement and no mention of the sibling run_co_companies as the alternative. Usage is inferable from the tool name and keyword parameter rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Directory of ~700 Craigslist regional sites with alias (the area value for searches), area code, hostname, country, region, coordinates, timezone and sub-areas. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Country (optional). e.g. US |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the burden, and it does disclose the returned field set plus the cost model ('Flat 5 points per successful run'), both useful. It omits side-effect/auth/pagination details, but for a static read-only directory lookup those are minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: an opening field inventory and a pricing note. The resource is front-loaded and nothing is filler, though the long field enumeration is somewhat dense given there is no output schema to lean on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-optional-param reference tool with no output schema, the description supplies the field inventory that the schema cannot, making it callable without further context. Adding explicit guidance on how the alias ties into the search siblings would close the last gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single optional 'country' parameter is fully documented in the schema (100% coverage, including an example), so the baseline is 3. The description mentions 'country' only as a returned field, not as a filtering input, adding no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete resource (a directory of ~700 Craigslist regional sites) and enumerates the fields it contains, which clearly separates it from siblings like run_craigslist_categories and run_craigslist_postings. The phrasing is passive ('Directory of...') rather than an explicit verb, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: calling the alias 'the area value for searches' hints that this tool is the lookup source for area parameters used by the posting/search siblings. There is no explicit when-to-use statement or named alternative, so the agent must infer the connection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every Craigslist posting category with its alias (the category value for searches), description and section. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Section (optional). Options: housing = Housing, for_sale = For sale, jobs = Jobs, gigs = Gigs, services = Services, community = Community, events = Events, resumes = Resumes, event_calendar = Event calendar |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does add one genuinely useful behavioral detail — 'Flat 5 points per successful run' cost — plus the shape of returned fields. But it never states this is a read-only lookup, whether the section argument changes the scope of results, or any rate/pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler; the resource and returned fields are front-loaded, and the cost note is placed last. Efficient, though the second sentence is a pricing aside rather than task-relevant guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, no-annotation, single-optional-param catalog tool with no output schema, the description covers what the tool returns (fields) and its cost. Nothing critical is missing, though a note on when to call it versus the areas list would complete the picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single optional 'section' enum is already fully documented in the schema. The description adds no syntax or filtering guidance beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('every ... category') and resource (Craigslist posting categories) plus the fields returned (alias, description, section). It clearly differs from run_craigslist_postings and run_craigslist_postings_search by being a category catalog. However, it never explicitly contrasts itself with the similar sibling run_craigslist_areas, leaving a small ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: calling the alias 'the category value for searches' hints this is a prerequisite lookup before running a postings search. There is no explicit when-to-use/when-not statement and no named alternative, so an agent must infer the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full Craigslist posting by id or URL: title, price, body text/HTML, category attributes with matching search filters, decoded VIN spec for vehicles, hiring company for jobs, images, location and dates. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| posting | Yes | Posting ID (22 characters) or URL. e.g. 2BsVfSUfZ3t4jqHF9sYzJL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the credit cost ('Flat 5 points per successful run') and the breadth of returned data, but says nothing about permissions, failure modes for expired/removed postings, or rate limiting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the resource and input method; the second sentence carries the non-obvious cost disclosure. Every clause earns its place, with only mild list density in the field enumeration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description's enumeration of returned fields (category attributes, decoded VIN spec, hiring company, images, location, dates) is genuinely load-bearing and makes the tool predictable. It is only slightly short on error/edge behavior for invalid or expired postings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents both accepted forms (22-character id or URL) with an example. The description's 'by id or URL' restates that without adding format, validation, or edge-case nuance, so the baseline of 3 applies for a single well-documented parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation (fetch a full Craigslist posting) and a precise input mode (by id or URL), and it enumerates the record's composition (title, price, body, VIN spec, images, dates), so an agent understands this is a single-item detail lookup. It does not explicitly name the sibling it contrasts with (run_craigslist_postings_search / run_craigslist_postings_seller), but the singular 'posting by id or URL' framing makes the distinction inferable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the requirement of an id or URL suggests this is the follow-up call once a posting reference is known, versus the search tool for discovery. There is no explicit when-to-use/when-not statement and no named alternative among the many craigslist siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search live Craigslist postings in any regional site by keyword, category, area/sub-area/postal/coordinates and 60+ vehicle, motorcycle, boat, housing, job, gig and event filters; returns title, price, date, location, images and category facets. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude | |
| lon | No | Longitude | |
| area | Yes | Area. e.g. sfbay | |
| free | No | Free items only | |
| sort | No | Sort by. Options: oldest = Oldest, price_asc = Price: low to high, price_desc = Price: high to low, distance = Distance, relevance = Relevance, upcoming = Upcoming | |
| paint | No | Paint color | |
| postal | No | Postal code. e.g. 94103 | |
| radius | No | Radius (miles) | |
| is_paid | No | Gig pay. Options: all = All, paid = Paid, unpaid = Unpaid | |
| keyword | No | Search term (optional). e.g. bike | |
| laundry | No | Laundry | |
| parking | No | Parking | |
| subarea | No | Sub-area. e.g. sfc | |
| category | No | Category (optional). e.g. sss | |
| language | No | Posting language | |
| max_sqft | No | Area, sq ft (max) | |
| min_sqft | No | Area, sq ft (min) | |
| purveyor | No | Sold by. Options: all = All, owner = Owner, dealer = Dealer | |
| boat_type | No | Boat type | |
| body_type | No | Body type | |
| condition | No | Condition | |
| crypto_ok | No | Crypto accepted | |
| cylinders | No | Cylinders | |
| fuel_type | No | Fuel | |
| has_image | No | Has image | |
| max_items | No | Max items (up to 500) | |
| max_price | No | Price (max) | |
| min_price | No | Price (min) | |
| drivetrain | No | Drivetrain | |
| make_model | No | Make and model. e.g. honda civic | |
| start_page | No | Starting page | |
| event_types | No | Event types | |
| rent_period | No | Rent period | |
| titles_only | No | Search titles only | |
| availability | No | Move-in availability. Options: all = All dates, within_30_days = Within 30 days, beyond_30_days = Beyond 30 days | |
| housing_type | No | Housing type | |
| is_nonprofit | No | Non-profit employers only | |
| max_bedrooms | No | Bedrooms (max) | |
| min_bedrooms | No | Bedrooms (min) | |
| posted_today | No | Posted today | |
| street_legal | No | Street legal only | |
| title_status | No | Title status | |
| transmission | No | Transmission | |
| is_internship | No | Internships only | |
| lost_or_found | No | Lost or found | |
| max_auto_year | No | Model year (max) | |
| max_bathrooms | No | Bathrooms (max) | |
| min_auto_year | No | Model year (min) | |
| min_bathrooms | No | Bathrooms (min) | |
| max_auto_miles | No | Odometer (max) | |
| min_auto_miles | No | Odometer (min) | |
| boat_propulsion | No | Propulsion | |
| employment_type | No | Employment type | |
| hide_duplicates | No | Hide duplicates | |
| max_boat_length | No | Length overall (max) | |
| min_boat_length | No | Length overall (min) | |
| motorcycle_type | No | Type | |
| housing_features | No | Required features | |
| is_telecommuting | No | Telecommuting allowed | |
| motorcycle_motor | No | Motor | |
| delivery_available | No | Delivery available | |
| max_monthly_payment | No | Monthly payment (max) | |
| min_monthly_payment | No | Monthly payment (min) | |
| max_year_manufactured | No | Year manufactured (max) | |
| min_year_manufactured | No | Year manufactured (min) | |
| max_engine_displacement_cc | No | Engine displacement, cc (max) | |
| min_engine_displacement_cc | No | Engine displacement, cc (min) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the returned fields (title, price, date, location, images, facets) and the cost model (1 point per returned record), but omits pagination behavior, rate limits, and auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the verb+resource, followed by return fields and cost. Appropriately sized for a tool with 67 parameters with no wasted prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations exist, so the description must carry returns and behavior. It covers the returned record shape and the cost model well; the main uncoved gaps (pagination, rate limits, auth) are relatively minor against a fully-described schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the field-level meaning is already documented. The description adds a small amount of meaning by grouping the 67 parameters into coherent filter families (vehicle, motorcycle, boat, housing, job, gig, event) and locator modes, but not enough to exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Search) and resource (live Craigslist postings) and defines the scope (any regional site) plus the breadth of filters and returned fields. It's clear and informative, though it doesn't explicitly name or distinguish itself from the very similar sibling run_craigslist_postings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: search postings by keyword/category/area or by the dozens of domain filters. There is no explicit when-to-use vs when-not guidance, no naming of an alternative sibling, and no prerequisites, so an agent must infer fitness from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All postings published by the seller of a given Craigslist posting (a dealer's, landlord's or shop's full inventory). 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: oldest = Oldest, price_asc = Price: low to high, price_desc = Price: high to low, distance = Distance, relevance = Relevance, upcoming = Upcoming | |
| posting | Yes | Posting ID or URL. e.g. 22-character posting id or a posting URL | |
| category | No | Category (optional). e.g. sss | |
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the cost model ('1 point per returned record'), which is real value, but says nothing about pagination behavior, result limits, or authentication, leaving gaps for a list-endpoint tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the resource and scope front-loaded and the billing note trailing. No filler; every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should say more about what a record contains and how to page through results. It covers the core purpose and cost but leaves return-shape and pagination to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 posting, sort, category, max_items, and start_page. The description adds only the notion of the seed posting; it does not enrich the other parameters, so the baseline 3 holds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and scope: 'All postings published by the seller of a given Craigslist posting', and clarifies with a parenthetical about full inventory. An agent can tell this apart from run_craigslist_postings or run_craigslist_postings_search, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'of a given Craigslist posting' implies you must supply a posting ID/URL and want that seller's other listings, but there is no explicit when-to-use vs alternatives or any exclusion guidance relative to the sibling search/list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches structured company data from a Crunchbase company URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state authentication requirements, rate limits, error behavior, or what 'structured company data' includes, and only weakly implies a read-only fetch operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the action and the input source immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter fetch tool, the description covers the core purpose and input. However, with no output schema and no annotations, it should ideally say more about the returned data, authentication needs, or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single input parameter has no schema description, but the description adds meaning by identifying the expected value as a Crunchbase company URL. It does not specify the URL format or give an example, so it partially compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Fetches), resource (structured company data), and source (Crunchbase company URL), so the agent knows this is a Crunchbase-specific company data tool. It does not explicitly contrast with the many other company-data siblings, but the source name provides enough differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use, when-not-to-use, or alternative-tool guidance. It only implies that a Crunchbase company URL is required, leaving the agent to infer when this tool should be selected over other company data tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one organisation from the Cyprus registry (Registrar of Companies, DRCOR) by registration number (HE, EE, AE, S, BN prefix) or registry link: name, status, registration date, registered office, type, previous names, directors / secretaries / partners, annual fees paid and counters. 10 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Registration number or registry URL. e.g. HE 7000 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose a meaningful behavioral trait: cost ('10 point per returned record'). It also enumerates the data returned (status, registered office, directors/secretaries/partners, filing counters), letting an agent judge whether one call suffices. It omits any note on permissions/auth or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and the lookup mechanism, followed by the returned fields and cost. The field enumeration is long but earns its place because there is no output schema; the only mild waste is the density of the field list in a single sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must cover both; listing the returned fields and the per-record cost does most of that work for a single-record lookup. The remaining gap is operational context (auth requirements, error behavior for invalid prefixes), which is not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real format information beyond the schema: the valid identifier prefixes (HE, EE, AE, S, BN) and the acceptance of a registry link. This helps an agent construct a valid input rather than only restating the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one organisation from the Cyprus registry (Registrar of Companies, DRCOR)') plus the exact lookup key ('by registration number ... or registry link'). The singular 'one organisation' plus the unique-identifier key implicitly distinguishes it from the sibling run_cy_companies_search, which returns sets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: the tool only accepts a registration number or registry link, so the agent can infer it needs a unique identifier. However, there is no explicit when-to-use / when-not-to-use guidance and no mention of run_cy_companies_search for name-based lookups, which is the most likely confusion given the large sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Cyprus company registry (Registrar of Companies, DRCOR) by name: name, registration number, type, status and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Company name. e.g. bank of cyprus | |
| max_items | No | Max items (up to 200) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses a cost model ('1 point per returned record') and the fields returned, but is silent on pagination behavior, rate limits, result caps, and whether the registry response can be truncated. It adds real value (cost) but leaves meaningful behavioral gaps for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence names the source and method, then lists outputs and pricing with no wasted words. It is dense but every clause carries information; only the slightly crammed output-field list keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description helpfully enumerates the returned fields, and the cost note is relevant for a metered search. Combined with the fully documented 4-param schema, an agent has enough to call it correctly, though paging/limit semantics are only covered by the schema, not elaborated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 keyword, status enum, max_items (up to 200) and start_page. The description only echoes the name-based nature of keyword and adds nothing about the enum or paging parameters, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: 'Search the Cyprus company registry (Registrar of Companies, DRCOR) by name', and it even enumerates returned fields (name, registration number, type, status, link). It is clearly the Cyprus-jurisdiction search, but it never explicitly contrasts with its nearest sibling run_cy_companies, so sibling differentiation is implied by the country scope rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by name' implies the lookup is keyword-driven, but there is no when-to-use guidance, no mention of when to prefer run_cy_companies or run_cy_company_filings, and no stated prerequisites. The agent must infer routing purely from the country token in the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the filings of one Cyprus organisation (Registrar of Companies, DRCOR) by registration number or registry link: file documents, charges and mortgages, translations, annual returns (HE32) or pending services, with form, date and page number. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| list | No | List. Options: documents = File documents (main), charges = Charges and mortgages documents, translations = Translations, he32 = Annual returns (HE32 archive), pending = Pending services | |
| company | Yes | Registration number or registry URL. e.g. HE 165 | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries full burden. It usefully discloses the credit cost ('1 point per returned record') and enumerates the filing categories, but says nothing about pagination behavior, result ordering, or failure modes for invalid registration numbers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads purpose and scope before enumerating categories and cost. Every clause carries information, though the long enumeration makes it slightly unwieldy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with full schema coverage and no output schema, the description covers purpose, accepted identifier forms, category options, and cost. Missing only pagination/return-shape guidance, which is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented including the 'list' enum. The description echoes the list categories and the registration-number-or-URL input format but adds no syntax or format detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (filings of one Cyprus organisation), names the registry (DRCOR) and the identifier inputs. It is clearly distinguishable from siblings like run_cy_companies (company lookup) and run_cy_companies_search, telling the agent this tool returns a known company's filings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'of one Cyprus organisation' implies you must already have a registration number or registry link, but it never states when to choose this over run_cy_companies_search or run_cy_companies. Usage is inferable rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Czech Republic commercial register (Justice.cz) by registration number (IČO, 8 digits) or registry URL: name, status, registration date, address and court file number. Also returns legal form, business scope, share capital, officers, shareholders and branches. 5 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | IČO or registry URL. e.g. 45274649 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does substantial work: it enumerates the return payload (name, status, registration date, address, court file, legal form, business scope, share capital, officers, shareholders, branches) and discloses cost ('5 point per returned record'). It omits auth requirements and rate limits, but the cost and return disclosure are meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences, front-loaded with the action and source before the return enumeration. The long list of returned fields is dense but each item earns its place by telling the agent what the call yields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description correctly takes responsibility for describing the return payload, and it does so thoroughly. Combined with the cost note, an agent has enough to call this correctly; only auth/error behavior is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents the single 'company' parameter with an example (e.g. 45274649). The description adds only minor detail ('8 digits'), so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: fetch one company from the Czech Republic commercial register. 'Get one company' implicitly contrasts with the sibling run_cz_companies_search, but that sibling is never named explicitly, so the differentiation is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives input identification (IČO or registry URL) but offers no explicit when-to-use guidance and does not route to run_cz_companies_search or run_cz_company_filings when a company name is known instead of an ID. Usage is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Czech Republic commercial register (Justice.cz) by company name: name, registration number (IČO), status, address and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Company name. e.g. škoda auto | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the cost model ('1 point per returned record') and lists the returned fields, but omits authentication requirements, rate limits, and read-only confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the purpose front-loaded and the return fields and cost presented compactly. No wasted words, and every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity search tool with full schema coverage and no output schema, the description provides the register name, search key, return fields, and cost. It is largely complete, though it could mention whether the search is exact or fuzzy and any auth requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all four parameters. The description adds no extra syntax, format, or meaning beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (Czech Republic commercial register / Justice.cz) and specifies the search key (company name). It does not explicitly differentiate itself from the sibling run_cz_companies or run_cz_company_filings, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives such as run_cz_companies or run_cz_company_filings. The description only states what it searches by, not when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the documents filed in the Czech Republic Collection of Documents (Sbírka listin, Justice.cz) for one company, by IČO or registry URL, newest first: document number, type, description, period, filing dates, pages and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | IČO or registry URL. e.g. 00177041 | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose meaningful traits: results are ordered newest first, the returned fields are enumerated (document number, type, description, period, filing dates, pages, link), and the metered cost ('1 point per returned record') is stated. It omits rate limits, auth/prerequisite conditions, and pagination behavior, so it is not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence: purpose first, then identifier format, ordering, output fields, and cost. Dense but every clause (order, fields, cost) carries information; slightly long but no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paginated list tool with no annotations and no output schema, the description covers what is returned and in what order, which is the key missing structured context. It is nearly sufficient, though it could better explain pagination/limit behavior tied to max_items and start_page.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 company, max_items and start_page; baseline is 3. The description reinforces how the required company parameter is supplied (IČO or registry URL) but adds nothing new about the two pagination parameters beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and a precisely scoped resource: documents filed in the Czech Republic Collection of Documents (Sbírka listin, Justice.cz) for one company. It is clearly distinguishable from sibling country filing tools (run_sk_company_filings, run_pl_company_filings, etc.) and from the Czech company-profile siblings run_cz_companies / run_cz_companies_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (retrieving filed documents for a single company identified by IČO or registry URL) but never states when to prefer this over run_cz_companies or run_cz_companies_search, nor any prerequisites or exclusions. Usage is inferable rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from Dealroom by slug or URL: tagline, HQ, founding year, sector, tier, valuation / revenue / headcount ranges, investors by round, ownership, funding events, alumni founders, footprint and investments. Dealroom shows ranges, not exact values, without a login. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Company slug or Dealroom URL. e.g. revolut |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses a real data limitation ('Dealroom shows ranges, not exact values, without a login') and a cost model ('Flat 5 points per successful run'). It also sketches the breadth of returned data, though it doesn't cover failure modes or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and identifier, then a single dense field list, closing with two useful caveats about granularity and cost. The field enumeration is long but each item earns its place by defining the return scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must describe what comes back, and it does so by listing the covered domains plus the ranges caveat. The main residual gap is how to resolve the slug when it isn't known, which is left to the search sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents the single parameter ('Company slug or Dealroom URL. e.g. revolut'). The description's 'by slug or URL' restates that rather than adding format or resolution guidance, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb and resource: 'Get one company from Dealroom by slug or URL', and it enumerates the returned fields (tagline, HQ, founding year, sector, valuation ranges, investors, etc.). The word 'one' plus 'by slug or URL' distinguishes it from the run_dealroom_companies_search sibling, though it never explicitly names that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The identifier requirement ('by slug or URL') implies you already have a resolved company, which suggests it follows a search step, but no explicit when-to-use or when-not guidance is given. No alternative tools are named, so usage must be inferred from the phrasing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Dealroom companies by keyword and/or tier, sector and country: name, tier, sector, HQ, founding year, numeric valuation and range, logo and link. At least one of keyword / tier / sector / country is required. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: valuation = Valuation, alphabetical = Alphabetical, founded = Founding year | |
| tier | No | Tier. Options: Centicorn = Centicorn, Colt = Colt, Decacorn = Decacorn, Gigacorn = Gigacorn, Listed = Listed, Mag 7 = Mag 7, Thoroughbred = Thoroughbred, Titan = Titan, Unicorn = Unicorn | |
| sector | No | Sector. Options: Fintech = Fintech, Biotech & Life Sciences = Biotech & Life Sciences, eCommerce & Marketplaces = eCommerce & Marketplaces, Health Tech & Medtech = Health Tech & Medtech, Other B2B Software = Other B2B Software, Energy = Energy, Consumer Services = Consumer Services, Transportation = Transportation, Marketing = Marketing, AI = AI, Cybersecurity = Cybersecurity, Food = Food, Semiconductors = Semiconductors, Edtech = Edtech, Robotics = Robotics, Space = Space, Defence = Defence, Aviation = Aviation | |
| country | No | Country. e.g. Germany | |
| keyword | No | Keyword. e.g. revolut | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page (60 per page) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does disclose the minimum-filter requirement and the cost model ('1 point per returned record'), which are meaningful behavioral facts. It says nothing about pagination limits, result caps beyond the schema, or auth, so the profile is incomplete for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences front-load the search scope, then the required-filter constraint and cost. Little waste, though the enumerated output fields are somewhat stuffed into the first sentence rather than prioritized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a fully described schema, no output schema, and a stated cost and filter constraint, an agent has enough to invoke this correctly. The missing piece is sibling disambiguation against run_dealroom_companies, which keeps it short of complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with all seven parameters documented, so the baseline is 3. The description echoes the returned fields and the at-least-one-filter rule but adds no value semantics (e.g., how keyword matching works or how sort interacts with pagination) beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (Dealroom companies) with the filter dimensions and even enumerates returned fields (name, tier, sector, HQ, founding year, valuation, logo, link). This is clear, but it never distinguishes itself from the sibling run_dealroom_companies, leaving the search-vs-direct distinction implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It supplies one real constraint ('At least one of keyword / tier / sector / country is required'), which is genuinely useful. However, it gives no when-to-use guidance relative to run_dealroom_companies or the investor siblings, nor any exclusions, so usage is only partially framed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one investor from Dealroom by slug or URL: type, HQ, rank, portfolio / unicorn / investment counts, links, biggest holdings, exits, portfolio analysis, market map, similar investors and key people. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| investor | Yes | Investor slug or Dealroom URL. e.g. 500-global |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden. It usefully discloses output content (portfolio, exits, market map, key people) and a cost model ('Flat 5 points per successful run'), but says nothing about auth requirements, rate limits, or whether it is a pure read with no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the verb and resource, then packs the payload and cost into a compact second clause. The field enumeration is long but each item conveys a distinct return category rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description compensates by listing the returned data categories and the point cost. A lookup tool with a single well-documented parameter is adequately covered, though read-only semantics and error behavior remain unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is only one parameter, so the schema already documents it fully. The phrase 'by slug or URL' reinforces the accepted formats but adds little beyond the schema's own example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one investor from Dealroom') and enumerates the returned data surface. The word 'one' plus the search-related siblings makes clear this is a singular-record lookup rather than a list/search tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the input form required (slug or URL) but never states when to prefer this over run_dealroom_investors_search or what prerequisites the slug requires. Usage is implied by the singular-resource framing rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Dealroom investor index by name keyword, type and country, ordered by Dealroom rank: name, type, country, HQ, portfolio companies, rank and link. With no filters it returns the top of the index. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Investor type. Options: Venture Capital = Venture Capital, Pension institution = Pension institution, Corporate = Corporate, Angel = Angel, Private Equity = Private Equity, Government = Government, Fund Of Funds = Fund Of Funds, Other = Other, Pension Fund = Pension Fund, Family Office = Family Office, Accelerator = Accelerator, Sovereign Wealth Fund = Sovereign Wealth Fund, Advisor = Advisor, Angel Fund = Angel Fund, University = University, Fund = Fund | |
| country | No | Country. e.g. France | |
| keyword | No | Keyword. e.g. capital | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does reasonably well: it discloses the result ordering (Dealroom rank), the behavior when all filters are omitted, and a cost signal ("1 point per returned record") that an agent should factor into call volume. It omits pagination behavior despite exposing start_page, and says nothing about auth or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the search scope before the returned fields and the no-filter default. Nothing is redundant, though the trailing cost note could be tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by enumerating the returned fields (name, type, country, HQ, portfolio companies, rank, link). Combined with fully described parameters, an agent has enough to call it correctly; only pagination semantics remain unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so type, country, keyword, max_items and start_page are already documented with examples and enum values. The description only echoes the keyword/type/country filters and adds no format or constraint detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (Dealroom investor index) plus the filters it accepts and the fields it returns, which an agent could not infer from the name alone. It stops short of explicitly distinguishing itself from the sibling run_dealroom_investors, which by contrast appears to be an unfiltered listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the no-filter behavior ("returns the top of the index"), which implies when a bare call is appropriate, but it never states when to use this over run_dealroom_investors or another investor source such as pitchbook_investors or tracxn_investors. Usage is implied rather than directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Denmark registry (CVR) by registration number or registry URL: name, status, registration date, address and legal form. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Registration number or registry URL. e.g. 24256790 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It usefully discloses the cost model ('Flat 5 points per successful run'), which is genuine behavioral context, but says nothing about auth, missing-record behavior, or whether failed lookups are billed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action and resource, followed immediately by the returned fields and cost. No filler and nothing to trim.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates well by listing the returned attributes (name, status, registration date, address, legal form). Gaps remain around error/not-found behavior for a lookup tool, but the core is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'company' parameter is already documented with the same example. The description's 'registration number or registry URL' mirrors the schema rather than adding meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get one company') and resource ('Denmark registry (CVR)') and enumerates the returned fields. The singular 'one company' implicitly distinguishes it from the sibling run_dk_companies_search bulk-lookup tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The accepted input (registration number or registry URL) is stated, which implies a direct single-record lookup, but the description never names run_dk_companies_search or any condition for choosing between them. Usage is left to inference from the singular noun.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Denmark company registry (CVR) by company name: name, registration number, status, address and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Company name. e.g. novo nordisk | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds useful behavioral context by disclosing the credit cost ('1 point per returned record') and the fields returned, but it omits whether the operation is read-only, how pagination behaves beyond the schema, and any rate or permission constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core purpose and followed immediately by return fields and cost. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter search tool with no output schema, the description supplies the essential missing piece by listing the returned fields and the cost model. It stops short of explaining pagination behavior or auth requirements, but the schema already covers all parameters, so the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents keyword, status, max_items, and start_page. The description only re-states 'by company name' (the keyword parameter) and adds no syntax, matching behavior, or filter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search the Denmark company registry (CVR) by company name') and lists the returned fields. This clearly distinguishes it from a generic lookup, but it never names or contrasts with the sibling lookup tool run_dk_companies, so it falls short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use or when-not-to-use guidance. It does not mention when to prefer this search over run_dk_companies (detail lookup) or other country-registry tools, nor does it explain any prerequisites or pagination usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Annual reports, announcements and registrations of one Danish company (CVR): date, type, description and document links. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Registration number or registry URL. e.g. 24256790 | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses the credit cost ('1 point per returned record') and implies a read-only listing of documents, but says nothing about pagination behavior, rate limits, or what happens when a company has no filings. The cost disclosure is real value, the rest of the behavioral profile is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler, front-loaded with the resource and scope before the record fields and cost. Every clause carries information, though the field list and cost could be ordered slightly more usefully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does the necessary work by enumerating the returned record fields (date, type, description, document links). For a 3-parameter, single-output tool this is nearly sufficient; missing pagination guidance for start_page/max_items is the only meaningful gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so company, max_items and start_page are already documented in the schema; the baseline of 3 applies. The description's field list ('date, type, description and document links') describes the return payload rather than the inputs, so it adds nothing new about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and scope: annual reports, announcements and registrations for one Danish company identified by CVR, plus the record fields returned. 'Of one Danish company' distinguishes it from the sibling run_dk_companies_search, though it never names that sibling explicitly, so differentiation is implicit rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance and no alternative named. The phrase 'of one Danish company (CVR)' hints that a registration number is required input, but nothing tells the agent how to obtain a CVR or when filings are preferable to run_dk_companies / run_dk_companies_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full eBay browse category tree: every department, category, and subcategory. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden. It usefully discloses cost ('Flat 5 points per successful run') and 'Get' implies a read-only operation, but it says nothing about response size, caching, or tree depth, and there are no annotations to cover that gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler: the purpose is front-loaded and the cost note follows immediately. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description is the only source of return-value information, and it only says the tree spans departments, categories, and subcategories without describing fields (IDs, names, hierarchy depth). Adequate for a zero-parameter tool but leaves the agent guessing about the payload.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, which is the baseline-4 case per the rubric. The description correctly implies no inputs are needed and adds nothing misleading about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Get the full eBay browse category tree,' and enumerates its scope ('every department, category, and subcategory'). It is clearly distinguishable from the other eBay siblings (run_ebay_item, run_ebay_item_search, run_ebay_product), though it does not explicitly name any of them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use statement, and no alternatives are named. However, the single-purpose, zero-parameter nature of a full category tree makes the intended usage strongly implied rather than ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full eBay listing details by item ID: title, price, condition, images, and seller. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| item | Yes | Item ID or URL. e.g. 336776720041 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose the cost model ('Flat 5 points per successful run'), which is genuine value beyond the schema, and lists returned fields. However it says nothing about authentication, rate limits, pagination, or failure behavior, so the transparency 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences that front-load the purpose before the call. The price note is short and earns its place, though it reads as bolted on rather than integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description usefully enumerates the returned fields and the cost, which is close to sufficient. It is missing the disambiguation from run_ebay_product/run_ebay_item_search that a packed eBay sibling set would warrant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the single 'item' parameter is already fully documented, including that it accepts an ID or a URL. The description only echoes 'by item ID' and actually omits the URL form, adding no meaning beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get full eBay listing details by item ID') and enumerates the returned fields, so the agent knows exactly what it retrieves. It doesn't disambiguate against the close siblings run_ebay_product or run_ebay_item_search, which look up nearly the same thing, leaving a residual selection ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by item ID' implies you must already have an identifier, but the description never says when to use this versus run_ebay_item_search (search) or run_ebay_product. No prerequisites, no exclusions, no alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search active eBay listings by keyword: title, price, condition, and seller summary. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: ending_soonest = Ending soonest, newly_listed = Newly listed, price_low = Price: low to high, price_high = Price: high to low | |
| keyword | Yes | Search term. e.g. wireless mouse | |
| condition | No | Condition. Options: new = New, open_box = Open box, used = Used, parts = For parts / not working | |
| max_items | No | Max items (up to 500) | |
| max_price | No | Max price | |
| min_price | No | Min price | |
| start_page | No | Starting page | |
| category_id | No | Category ID. e.g. 58058 | |
| buying_format | No | Buying format. Options: auction = Auction, buy_it_now = Buy It Now |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral context. It adds useful facts: the search covers active listings only and costs 1 point per returned record. However, it omits pagination behavior, rate/credit details beyond the per-record note, and what the result structure looks like beyond named fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the core purpose front-loaded and no wasted text. The cost note is useful and concise. The colon phrase is slightly ambiguous between returned fields and search dimensions, but the overall structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter search tool with full schema coverage and no output schema, the description provides enough to understand purpose, scope, returned fields, and per-record cost. It could be stronger with sibling routing guidance or pagination/result-count context, but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all 9 parameters, including enums for sort, condition, and buying format. The description adds little parameter-level meaning beyond mentioning keyword-based search; the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: search active eBay listings by keyword. It also names the returned fields (title, price, condition, seller summary), which clarifies the tool's output. It does not explicitly differentiate itself from eBay siblings like run_ebay_item or run_ebay_seller_items, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for keyword searches of active eBay listings, but gives no explicit when-to-use guidance, exclusions, or alternatives. With many eBay sibling tools available, an agent receives no routing help for choosing between keyword search, item lookup, seller items, or category browsing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get eBay catalog product details by ePID: brand, model, rating, price range, and specs. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | ePID or URL. e.g. 1234567890 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It does add genuinely useful behavioral context by stating the cost profile ('Flat 5 points per successful run'), which is more than most definitions provide, but it omits whether the call is read-only, what happens on an invalid ePID, or any rate-limit/error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core purpose and output fields, followed by a compact cost note. No filler and nothing repeated from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description compensates by listing the returned fields (brand, model, rating, price range, specs). For a simple single-parameter read tool with no annotations, that is close to sufficient; the main gap is the missing guidance on when to prefer this over sibling eBay tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single parameter is already documented ('ePID or URL. e.g. 1234567890'). The description's 'by ePID' mildly narrows the accepted input versus the schema's ePID-or-URL, adding no new semantic detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get'), a clearly scoped resource ('eBay catalog product details'), and an identifier ('by ePID'), and it enumerates the returned fields. It implicitly distinguishes itself from listing-oriented siblings like run_ebay_item or run_ebay_item_search by emphasizing 'catalog product', but it never names or contrasts those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no reference to alternatives. An agent cannot tell from the text alone whether to reach for this versus run_ebay_item_search or run_ebay_item, particularly since 'ePID' vs 'item ID' is the only differentiator and it is not explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get buyer reviews for an eBay catalog product by ePID: rating, text, and author. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | ePID or URL. e.g. 1234567890 | |
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does add one genuinely useful behavioral fact – the cost model ('1 point per returned record') – and lists the returned fields, but it says nothing about pagination behavior, rate limits, or failure modes when the ePID is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero waste; the identity and scope come first, and the cost note is a single appended clause that earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so naming the returned fields (rating, text, author) is a real contribution, and the cost line covers a behavioral gap. What remains thin is pagination/limit behavior, which the schema only implies via max_items and start_page.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 product, max_items, and start_page. The description reinforces that 'product' accepts an ePID but adds no syntax, format, or constraint detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (Get) plus resource (buyer reviews) scoped to an eBay catalog product by ePID, and it names the returned fields. This distinguishes it in spirit from run_ebay_seller_feedback and run_ebay_product, though it never explicitly contrasts itself with those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but gives no when-to-use guidance, no prerequisites, and no mention of the adjacent eBay tools (run_ebay_product, run_ebay_seller_feedback) an agent might confuse it with. Usage is only inferable from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an eBay seller/store profile by username: feedback, ratings, and store details. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| seller | Yes | Username or store URL. e.g. cocosmartphones |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose a useful behavioral trait: a flat cost of 5 points per successful run (implying failed runs are not charged). However, it never states that this is a read-only operation, nor does it describe rate limits or how large the response is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the purpose and ending with the cost note; no wasted phrasing. It is slightly terse on guidance, but nothing is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup with no output schema, the description covers what is returned (feedback, ratings, store details) and the cost, which is the key decision-relevant context. The main omission is the absent usage/alternative routing, which is scored separately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the 'seller' param is documented with a concrete example ('cocosmartphones'), so the baseline is 3. The description's 'by username' adds only a slight nudge by clarifying the identifier is a username, but the schema already covers the store-URL alternative.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Get an eBay seller/store profile by username') and enumerates the returned payload (feedback, ratings, store details). It is clearly distinguishable from the many non-eBay siblings, though it does not explicitly differentiate itself from the close sibling run_ebay_seller_feedback, whose scope overlaps with the 'feedback' it claims to return.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus run_ebay_seller_feedback or run_ebay_seller_items, no prerequisites, and no exclusions. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get feedback reviews received by an eBay seller: rating, reviewer, and related item. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| seller | Yes | Username or store URL. e.g. cocosmartphones | |
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the per-record cost (1 point) and the returned fields, which is useful beyond schema, but omits read-only status, pagination behavior, rate limits, and authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and then cost. No wasted words, and the structure makes the tool's function and pricing immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description appropriately lists returned fields (rating, reviewer, related item). With 100% schema coverage for inputs and clear purpose, it is largely complete, though pagination interplay is left to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 seller, max_items, and start_page. The description adds no parameter-level meaning beyond what the schema provides, making baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb 'Get' and resource 'feedback reviews received by an eBay seller', and names returned fields (rating, reviewer, related item). This distinguishes it from siblings like run_ebay_seller (seller profile) and run_ebay_product_reviews (product reviews), even without explicitly naming alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no exclusions, and no mention of alternative tools. The agent must infer from the name and resource that this is for seller feedback rather than seller profile or seller items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List active eBay listings for a seller: title, price, condition, and image. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| seller | Yes | Username or store URL. e.g. cocosmartphones | |
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It usefully discloses two behaviors beyond the schema: only active listings are returned, and the call costs '1 point per returned record' (a cost/rate disclosure). It does not mention auth requirements, pagination limits, or behavior for sellers with no matches.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the operation and its scope, followed by the return fields and cost. Every clause carries information; nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description does well to enumerate the returned fields, but it omits pagination behavior (how start_page/max_items interact, total counts) and any indication of what an empty result means. Adequate but with clear gaps for a paginated list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (seller, max_items, start_page) are already documented in the schema. The description adds no parameter-level meaning beyond restating the seller framing, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List active eBay listings for a seller') and even enumerates the returned fields (title, price, condition, image). It clearly differs from run_ebay_seller and run_ebay_seller_feedback by nature of 'listings', but it never explicitly names those siblings to disambiguate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'active' implies a status filter, but there is no explicit when-to-use guidance and no routing to alternatives like run_ebay_item_search (keyword-scoped) or run_ebay_item (single-item). Against a sibling set this dense, the agent gets no exclusion or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Ecuador registry (Superintendencia de Compañías) by expediente number or RUC: expediente, RUC and registered name. 5 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Expediente or RUC. e.g. 7154 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses a cost signal ('5 point per returned record') and that exactly one record is returned, but omits permissions, rate limits, and failure behavior when the identifier is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact clauses with the primary action front-loaded, then the key forms and returned fields. No filler, though the trailing field list ('expediente, RUC and registered name') is slightly compressed and could be misread as input rather than output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup with no output schema or annotations, the description covers the registry, the accepted identifier types, the returned fields, and the cost. That is close to sufficient, with only auth/error behavior left unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With a single parameter at 100% schema coverage, the schema already documents 'company' as 'Expediente or RUC. e.g. 7154'. The description restates the same key information without adding format rules or validation guidance, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one company from the Ecuador registry') plus the authoritative source (Superintendencia de Compañías) and the lookup keys. The 'one company' phrasing implicitly separates it from the plural search sibling (run_ec_companies_search), though the sibling is not named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the requirement of an expediente or RUC signals this is a single-entity lookup for a known identifier. It never states when to prefer this over run_ec_companies_search or what to do if only a name is known.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Ecuador company registry (Superintendencia de Compañías) by company name: expediente number, RUC and name (the registry returns up to 15 matches per search). 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Company name. e.g. pronaca | |
| max_items | No | Max items (up to 15) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose two useful behaviors — the registry returns up to 15 matches per search and costs 1 point per returned record — but says nothing about authentication, error behavior, or what happens on zero matches. Partial coverage only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is front-loaded with the primary action and resource, and every clause carries information (registry, fields, cap, cost). The parenthetical structure makes it slightly run-on, but there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description compensates reasonably by disclosing the result cap and per-record cost. It stops short of describing return fields or credentials, but for a two-param search tool it is close to complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (keyword, max_items) are already documented in the schema. The description restates the name-based input and the 15-item cap but adds no syntax, format, or matching-rule detail beyond what the schema provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search') and resource ('Ecuador company registry (Superintendencia de Compañías)'), and lists the identifying fields (expediente number, RUC, name). It's clear and specific, but it never explicitly distinguishes itself from the sibling run_ec_companies, which presumably retrieves a known company, leaving the search-vs-fetch split to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied — you search by company name — but there is no explicit when-to-use, when-not-to-use, or pointer to an alternative such as run_ec_companies for direct lookups. An agent can infer the context but receives no routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Estonia registry (e-Business Register) by registration number or registry URL: name, status, registration date, address and legal form. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Registration number or registry URL. e.g. 12417834 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds genuine value by disclosing the cost model ('Flat 5 points per successful run') and the returned fields, but says nothing about auth/permission needs, rate limits, or what happens on an unknown registration number.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: purpose and output fields first, cost second. Front-loaded and free of filler, though the cost sentence could arguably be separated from the functional description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description supplies the key missing context: what a single-company lookup returns and what it costs. It is close to sufficient for a one-parameter read tool; only error/not-found behavior is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'company' parameter already documents its accepted formats and an example. The description restates 'registration number or registry URL' without adding syntax or validation detail beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get), a precisely scoped resource (one company from the Estonia e-Business Register), the input form (registration number or registry URL), and the fields returned. The phrase 'one company' implicitly separates it from the sibling run_ee_companies_search, so an agent can route correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The input form implies when the tool applies (you already have a reg number or registry URL), but there is no explicit when-to-use/when-not guidance and the search sibling run_ee_companies_search is never named as the alternative for name-based lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Estonia company registry (e-Business Register) by company name: name, registration number, status, address and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Company name. e.g. bolt | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the billing model ('1 point per returned record'), which is real behavioral context absent from the schema, but it says nothing about pagination behavior, rate limits, auth requirements, or whether the search is name-only versus fuzzy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single tight sentence that front-loads the verb and resource before the field list and cost note. Minor padding from enumerating returned fields, but nothing wasteful enough to penalize more heavily.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description gives a partial sense of the returned fields and a cost model, but omits pagination/capping behavior and does not clarify its relationship to neighboring Estonia tools. Adequate but with clear gaps for a registry search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description only echoes the keyword parameter ('by company name') and adds nothing about the status enum, max_items limit, or start_page semantics beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (Estonia company registry / e-Business Register) scoped by company name, and lists the fields returned. It is clear what the tool does, but it never explicitly distinguishes itself from close siblings like run_ee_companies or run_ee_company_documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance, no mention of when this search tool is preferable to run_ee_companies or the documents/filings siblings, and no stated prerequisites. Usage is only implied by 'Search ... by company name'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Annual reports and documents of one Estonian company (e-Business Register): date, type, title and download links. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Registration number or registry URL. e.g. 12417834 | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It usefully discloses the cost model ('1 point per returned record') and lists the returned fields, but it does not explain pagination behavior, permissions or authentication needs, or error handling for missing companies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the resource and source before listing returned fields and cost. It contains no filler, though it could be slightly stronger with an explicit verb at the start.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only document lookup tool with a fully described input schema and no output schema, the description gives enough context: source register, single-company scope, returned fields, and cost. It does not cover authentication or error conditions, but the essential information for calling the tool is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented in the input schema. The description adds only the notion of a single-company lookup and returned document fields, without elaborating on parameter formats beyond what the schema provides, making the baseline score appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as annual reports and documents for one Estonian company from the e-Business Register, which distinguishes it from company-search siblings. It lacks an explicit verb and does not name the specific alternative to use when searching for a company, but the intended purpose is readily apparent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'one Estonian company', suggesting the tool should be used when a company identifier is already known, while sibling tools like run_ee_companies_search are presumably for finding companies. However, the description does not explicitly state when to use this tool versus alternatives or mention prerequisites such as needing a registration number.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enriches a known email address with profile-related data when available.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discharges very little of it. 'When available' hints that enrichment can fail or return partial results, but there is no mention of cost/credits, rate limits, auth requirements, or what fields come back for a valid address.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One tight sentence with the resource and the qualifier front-loaded; no filler. It is appropriately sized, though slightly thin for what it is trying to convey.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and an undocumented parameter, the description should explain what 'profile-related data' concretely contains and what happens on a miss. Those gaps are exactly where an agent would need help, and they are left open.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single parameter, so the description must compensate. It only restates that the input is a 'known email address', adding nothing about format, normalization, or whether aliases/plus-addressing are accepted beyond the schema's already-present email format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (enriches) plus resource (a known email address) and a stated output class (profile-related data). It does not name or distinguish itself from close siblings like run_email_finder or run_email_validation, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'a known email address' implicitly sets the precondition that the caller already possesses the address, which quietly separates it from run_email_finder. Beyond that there is no explicit when-to-use, when-not-to-use, or named alternative, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds a professional email address using company domain, first name, and last name.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| last_name | Yes | ||
| first_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says only that the tool finds an email and does not explain success rates, whether results are guessed versus verified, failure behavior, permissions, or output characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted language and is front-loaded with the core purpose and required inputs. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and no parameter descriptions, the context is very thin. The description covers the basic action and inputs but omits return behavior, failure modes, and sibling differentiation, which are necessary for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It names company domain, first name, and last name, but does not specify accepted domain formats, name handling, or what happens with missing inputs, adding only minimal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: finds a professional email address. It also names the three required inputs, so the agent can distinguish it from generic search or validation tools. However, it does not explicitly differentiate it from close siblings like run_linkedin_email or run_email_enrichment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The required inputs imply that the tool is used when a company domain, first name, and last name are known, but the description gives no explicit when-to-use guidance. It also does not mention alternatives such as run_linkedin_email, run_email_enrichment, or run_email_validation, leaving the agent to infer routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates an email address and returns deliverability signals.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It hints that the call is read-only and returns 'deliverability signals', but doesn't disclose what validation depth is performed (syntax, MX, SMTP probe), whether it requires credentials/rate limits, or how long it takes. Thin for a zero-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the purpose is stated immediately. It is efficient, though arguably under-specified rather than maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description does say a result set comes back, which is useful. However 'deliverability signals' is vague about what an agent will actually receive (valid/invalid/risky/catch-all?), leaving the return contract underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter and schema description coverage is 0%, but the parameter name ('email') and format are self-evident from the schema. The description adds 'email address' but nothing about format nuance, normalization, or edge cases, so it neither harms nor compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('validates') and resource ('email address') plus the nature of the result ('deliverability signals'). It is reasonably distinct from run_email_enrichment and run_email_finder in the sibling list, though it never explicitly names those alternatives to draw the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus run_email_enrichment, run_email_finder, or run_linkedin_email, all of which appear in the sibling list. No prerequisites or conditions given; the agent must infer the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Spain registry (Registro Mercantil, Registradores de España open-data directory) by NIF/CIF or registry link: name, status (Vigente / Liquidada / Concurso), address, legal form, registry office and sheet number, IRUS and EUID identifiers, CNAE/NACE activity, website, special situation, administrators and officers with their roles, and other registry entries under the same NIF such as branches. 10 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | NIF/CIF or registry URL. e.g. A15075062 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose a meaningful trait beyond the schema — the '10 point per returned record' cost — and enumerates the response payload in detail. However, it says nothing about error behavior for an invalid NIF, authentication requirements, or rate limits for a paid registry lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and source, then a field enumeration, and the cost constraint is tacked on clearly at the end. The field list is long but every item informs the agent about available output, so it largely earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully enumerates the returned fields (status, address, legal form, identifiers, officers, branches, etc.) and the cost, which is exactly the information an agent needs to decide whether to call it. Only the lack of error/permission handling for the lookup keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'company' parameter, and the description's mention of 'NIF/CIF or registry link' merely restates what the schema already documents. Baseline 3 is appropriate when the schema does all the parameter work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one company from the Spain registry') and immediately distinguishes itself from the sibling run_es_companies_search by being a single-record exact lookup. The field list confirms exactly what comes back, so an agent can tell it apart from the search variant without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context by naming the identifier input (NIF/CIF or registry link) and by saying 'get one company', which contrasts with the sibling search tool, but it never explicitly says when to use this versus run_es_companies_search or what to do if the NIF is unknown. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Spain company registry (Registro Mercantil, Registradores de España open-data directory) by company name, brand or NIF: name, NIF/CIF, status, address, legal form, registry office, sheet number, EUID, CNAE activity and link. 2 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Company name. e.g. inditex | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It usefully adds the cost model ('2 point per returned record') and enumerates the fields returned, which is valuable with no output schema. However, it omits any note on auth/permissions, rate limits, or pagination behavior, so coverage is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the verb and data source. The field enumeration is compact and the cost note is a short standalone sentence. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, listing the returned fields is the right move, and the cost note is helpful. But the description is silent on pagination semantics (start_page, max_items exist in the schema) and on when this tool is the correct choice, leaving gaps for an agent navigating a large registry-tool family.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description meaningfully exceeds that by expanding the required 'keyword' parameter's semantics: the schema describes it only as 'Company name', whereas the description states it accepts name, brand, or NIF. That is a genuine clarification beyond structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: 'Search the Spain company registry' names both the action and the exact data source (Registro Mercantil, Registradores de España). It even enumerates the returned fields, so the agent knows what data comes back. It does not, however, differentiate itself from the sibling run_es_companies or the many other run_XX_companies_search tools beyond the country token.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a search use case ('by company name, brand or NIF') but never states when to use this versus run_es_companies (the non-search sibling) or any other registry tool. No exclusions, prerequisites, or routing guidance are given, leaving the agent to infer selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one startup from the EU-Startups database by slug or URL: tagline, description, country, city, tags, founding year, total funding, website, status, social links and related articles. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Startup slug or EU-Startups URL. e.g. vista-ai |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose the returned field set and the cost model ('Flat 5 points per successful run'), which is genuinely useful context, but it says nothing about failure behavior when a slug is invalid, auth requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action and source, with the field list and cost note appended. The field enumeration is long but earns its place since no output schema exists to describe the return shape.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations exist, so the description must carry the return-value and behavior load; it lists the returned fields and discloses cost, covering most of the gap. Only error/edge-case behavior is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents the single 'company' parameter with an example. The description adds marginal value by confirming slug OR URL are both acceptable, reinforcing the schema's single example. With one well-documented parameter, semantics are effectively complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one startup from the EU-Startups database') plus the lookup key (slug or URL), which distinguishes it functionally from run_eustartups_directory_search. It stops short of naming the sibling search tool, so differentiation is inferred rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'by slug or URL' phrasing implies this is for direct single-entity lookups and that search should be used otherwise, but no when-to-use or when-not-to-use guidance is stated. The agent must infer when this beats run_eustartups_directory_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The country categories of the EU-Startups database with their slugs (use them as the country filter of the directory search), names, links and startup counts. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses useful context the schema cannot: the exact fields returned and a cost signal ('Flat 5 points per successful run'). However, it does not state the read-only nature, pagination, or auth requirements, so the safety profile is only implied by 'categories'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both front-loaded with the highest-value information first (what is returned, then how to use it, then cost). No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must explain the payload itself, which it does by listing the returned fields and the cost. For a zero-parameter taxonomy endpoint, this is nearly complete, missing only explicit read-only/pagination statements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero input parameters, so the baseline is 4. The description correctly implies a no-argument call and does not need to explain any parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific resource retrieved: the country categories of the EU-Startups database, with an enumeration of the returned fields (slugs, names, links, startup counts). It is distinguishable from siblings like run_eustartups_directory_search by being the category-listing endpoint, though it never names an alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for the returned data: 'use them as the country filter of the directory search,' which tells the agent exactly how this tool fits into a workflow. It does not state explicit when-not-to-use conditions, but the routing intent is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the EU-Startups startup database by country category (e.g. german-startups) or by keyword: name, city, tags, founding year, logo and link. Provide a country or a keyword. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Country category. e.g. german-startups | |
| keyword | No | Keyword (instead of country). e.g. ai | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the pricing model ('1 point per returned record'), which is real behavioral context, but omits auth requirements, rate limits, or pagination behavior for the max_items/start_page controls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the core purpose and query modes. Slightly muddled by the field list 'name, city, tags, founding year, logo and link' placed after 'by keyword', which reads ambiguously as searchable fields rather than return fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter search tool with full schema coverage and no output schema, the description covers purpose, entry modes, and cost. The main gaps are the absence of sibling differentiation and any handling note when neither country nor keyword is given.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 four parameters including the country/keyword examples. The description restates the country-vs-keyword choice but adds no syntax or format detail beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Search) and resource (EU-Startups startup database) and clarifies the two query modes: by country category or by keyword. It is clearly a search tool, though it never names or contrasts against the obvious siblings run_eustartups_directory and run_eustartups_directory_categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives operational guidance ('Provide a country or a keyword'), implying the two entry paths, but offers no when-to-use vs. alternatives, no statement of what happens if both or neither are supplied, and no differentiation from the directory/categories siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one investor from the EU-Startups investor database by slug or URL: type, HQ country, website, investment areas, typical investment, funding stages, LinkedIn and contact email. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| investor | Yes | Investor slug or EU-Startups URL. e.g. vitaminc |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It helpfully discloses the returned fields and the cost model ('Flat 5 points per successful run'), which is real behavioral context. However, it says nothing about failure behavior, auth requirements, rate limits, or what happens with an invalid slug.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single well-structured sentence that front-loads the verb and resource, then enumerates the payload and the cost. The eight-field list is slightly long but each item is informative, so little is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly compensates by listing the fields returned (type, HQ country, website, investment areas, typical investment, funding stages, LinkedIn, contact email) and adds the point cost. It is complete enough to call correctly, though it omits error/empty-result behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter already documents that it accepts a slug or EU-Startups URL with an example. The description's 'by slug or URL' restates the schema rather than adding syntax, format, or edge-case detail, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Get one investor from the EU-Startups investor database') and scopes it to a single record via slug or URL, which implicitly distinguishes it from the sibling search tool. It stops short of explicitly naming run_eustartups_investors_search as the alternative, so it lands at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the agent can infer it should call this when it already has an investor slug or URL. There is no explicit statement of when to use this versus run_eustartups_investors_search or run_eustartups_directory, and no prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the EU-Startups investor database by name, type and HQ country: type, HQ, investment areas, typical investment, funding stage and link. All filters are optional. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Investor type. Options: vc = VC firm, accelerator = Accelerator, corporate = Corporate VC | |
| country | No | HQ country (ISO-2). e.g. DE | |
| keyword | No | Investor name. e.g. capital | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose one meaningful trait not present in the schema: the cost model ('1 point per returned record'). It says nothing about pagination behavior, result limits, or authentication needs, so coverage remains partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences and a short fragment, with the verb and resource front-loaded. Slightly muddied by the colon list, which reads ambiguously as either filters or returned fields, but overall tight with no wasted prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Five optional parameters, 100% schema coverage, and no output schema; the description partially compensates by enumerating returned fields and stating the credit cost. An agent has enough to invoke it correctly, though result ordering and paging behavior remain unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 five parameters including the enum values and ISO-2 country format. The description echoes the filter axes (name, type, HQ country) without adding syntax or format detail, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) plus the exact resource (EU-Startups investor database) and enumerates the returnable fields (type, HQ, investment areas, typical investment, funding stage, link). It implies the search variant versus the sibling run_eustartups_investors, but never names or contrasts that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The line 'All filters are optional' tells the agent the tool can be invoked with no arguments, which is genuine usage information. However, there is no statement of when to prefer this over run_eustartups_investors, run_eustartups_directory_search, or the many other investor-search siblings, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Loads a page by URL and extracts structured data.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| settings | Yes | ||
| instructions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden but says only that it 'loads' a page. It does not disclose auth requirements, rate limits, whether extraction is dynamic/JS-rendered, what the 'instructions' parameter controls, or what the result looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler, but it is under-specified rather than genuinely concise. It is efficient but leaves too much unsaid for a 3-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three required params, a nested object, no annotations, and no output schema, one sentence is far too thin. The agent lacks guidance on instructions semantics, settings behavior, and expected output, making correct invocation largely guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for three required parameters, including a nested settings object with country_code and extract_schema_json. The phrase 'by URL' loosely maps to the url param but the description adds no meaning for 'instructions' or the settings sub-fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('loads a page') and outcome ('extracts structured data') with the input source ('by URL'), so the agent knows exactly what the tool does. However, it offers no differentiation from the many sibling extraction tools, which is the main gap at this level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use, when-not-to-use, or alternative routing is given. With dozens of site-specific sibling extractors (run_amazon_product, run_ebay_item, etc.) the agent gets no signal on when this generic extractor is preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Finland registry (PRH / YTJ) by Business ID (Y-tunnus) or registry URL: name, status, registration date, address, legal form, names, registrations, tax debt status and Business ID history. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Business ID (Y-tunnus) or registry URL. e.g. 0112038-9 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does a fair job: it discloses the returned data set (status, registration date, address, legal form, registrations, tax debt status, Business ID history) and the cost model ('Flat 5 points per successful run'). It omits auth/permission requirements and error behavior, and the read-only nature is only implied by 'Get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler. The core verb+resource+key is front-loaded, the returned-field list follows, and the cost note is a compact trailing sentence that earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description compensates well by enumerating the returned fields and disclosing the billing cost. It is nearly complete for a single-record lookup, though it could note the read-only nature and any failure mode for an unknown Business ID.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'company' parameter is already documented in the schema with the same Business ID/URL detail and example. The description repeats that information rather than adding new semantics such as format normalization, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one company from the Finland registry'), names the data source (PRH / YTJ), and enumerates the returned fields. The phrase 'one company' plus the registry source distinguishes it from the sibling run_fi_companies_search, which is the multi-result search counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly frames the use case and the accepted input forms ('by Business ID (Y-tunnus) or registry URL'), which is enough context to know when to reach for this single-entity lookup. It does not, however, explicitly name run_fi_companies_search as the alternative for finding a company by name, so routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Finland company registry (PRH / YTJ) by company name: name, Business ID, status, municipality and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Company name. e.g. nokia | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description carries the full burden and partially delivers: '1 point per returned record' is a genuinely valuable cost trait that an agent cannot infer from the schema, and the PRH/YTJ attribution tells the agent what coverage to expect. However, it omits pagination behavior (despite start_page/max_items params), result-cap behavior at 250 items, and any note that this is a read-only lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence that front-loads the registry and the search key before the secondary detail about returned fields. Every clause carries information; only the return-field enumeration is slightly padded given it isn't a parameter concern.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the enumeration of returned fields (name, Business ID, status, municipality, link) is a meaningful compensation and the agent knows roughly what comes back. Missing pieces: no differentiation from run_fi_companies, and no statement of how pagination/results behave for a search that can span many pages.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so keyword, status, max_items and start_page are already fully documented with examples and bounds — the description adds nothing to them. The listed fields (name, Business ID, status, municipality, link) are return values rather than parameters, so they don't compensate for anything in the schema. Baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — 'Search the Finland company registry (PRH / YTJ) by company name' — and even names the authoritative data sources, so an agent immediately knows this is a Finnish company name lookup. It does not distinguish itself from the sibling run_fi_companies, which is the one likely confusion, but the verb+resource pairing is otherwise unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says the search is 'by company name', which implies the keyword parameter is the entry point, but there is no explicit when-to-use versus run_fi_companies (which presumably resolves a single known company) or versus the other ~40 country search tools. No prerequisites, no exclusions, no mention of what happens when no match is found.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full Flipkart product details by item id or product URL: title, brand, price, MRP, discount, images, color, rating, category, breadcrumbs, availability, condition and recent reviews. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Item ID or product URL. e.g. itm235cd318bde73 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the cost model ('Flat 5 points per successful run') and the full field set that comes back, which is real behavioral value. However it says nothing about authentication, rate limits, or error behavior for a missing/invalid id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and resource, followed by the cost note. The long field enumeration is informative but slightly heavy; nothing is wasted, though it could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description's field list does useful work in telling the agent what comes back. For a single-parameter retrieval tool this is close to complete, with only auth/error behavior left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is a single parameter, so the schema already documents the accepted value. The phrase 'by item id or product URL' mirrors the schema's own description and adds no extra syntax or format detail, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Get) and resource (full Flipkart product details) and enumerates the returned fields (title, brand, price, MRP, discount, images, etc.), which is far more than a restatement of the name. It doesn't explicitly differentiate itself from close siblings like run_flipkart_product_search or run_flipkart_product_reviews, so it falls short of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says the input must be an item id or product URL but gives no when-to-use guidance, no conditions selecting it over run_flipkart_product_search or run_flipkart_product_reviews, and no exclusions. Usage is only implied by the accepted input format.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get customer reviews for a Flipkart product: rating, title, text, author, date, location, certified-buyer flag, helpful/downvote counts and photos. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Item ID or product URL. e.g. itm235cd318bde73 | |
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does add genuine value by enumerating the review fields (certified-buyer flag, helpful/downvote counts, photos) and the cost model ('1 point per returned record'). However, it says nothing about pagination behavior, prerequisites, or rate limits, so the behavioral picture is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler: the resource and return fields come first, followed by the cost note. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema, the description usefully explains the return contents and cost, which compensates for the missing output schema. It still omits pagination semantics and any prerequisite/auth context, leaving gaps for an agent planning a multi-page pull.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 product, max_items, and start_page with constraints and an example. The description adds no syntax or format detail beyond what the schema provides; baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb+resource ('Get customer reviews for a Flipkart product') and enumerates the returned fields, so an agent can immediately distinguish this from run_flipkart_product or run_flipkart_product_search. It does not explicitly name a sibling, so it falls short of the 5 bar for direct differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance and no mention of alternatives like run_flipkart_product for metadata or run_flipkart_product_search for discovery. The agent must infer the appropriate context purely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Flipkart products by keyword: id, title, brand, price, MRP, discount, image, key specs, rating and review counts. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Search term. e.g. wireless earbuds | |
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the '1 point per returned record' cost model and the shape of returned records, but says nothing about pagination behavior, auth requirements, or rate limits for a search that accepts start_page and max_items.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and resource, followed by the output fields and cost. The dense field enumeration is informative rather than filler, though it slightly blurs the line between description and output documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema, the returned-field list usefully compensates, and the per-record cost is disclosed. However, missing pagination semantics for start_page/max_items and any usage routing leave real gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so keyword, max_items, and start_page are already documented in the schema. The description adds only 'by keyword' and the returned-field list, which is return-shape rather than parameter meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (Flipkart products) scoped by keyword, and enumerates the returned fields. The platform name implicitly separates it from the many sibling *_product_search tools on other marketplaces, though it never explicitly contrasts with run_flipkart_product or run_flipkart_product_reviews.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance and no routing to alternatives such as run_flipkart_product (single-product detail) or run_flipkart_product_reviews. The only usage hint is the implicit 'by keyword' phrasing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Flipkart seller offering a given product: name, rating, years on Flipkart, units sold, quality/speed scores, product/service quality ratings and description. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Item ID or product URL. e.g. itm4d0125d9c2c65 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses the return payload's fields and the billing model ('Flat 5 points per successful run'), which the schema does not cover. It omits auth/rate-limit details, so it is strong but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and resource, followed by the return fields and cost in a compact two-sentence block. The attribute list is slightly run-on but each item carries informational weight given there is no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, no-output-schema tool, the description tells the agent what it gets back and what it costs, which is the material context. The only omission is any indication of error/empty cases (e.g. product without a seller).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'product' parameter is already documented with an example (itm4d0125d9c2c65). The description only references 'a given product' without adding format or syntax meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get') and resource ('the Flipkart seller offering a given product') and enumerates the returned attributes (name, rating, years on Flipkart, units sold, quality/speed scores, ratings, description). This clearly distinguishes it from sibling run_flipkart_product, which returns the product rather than its seller.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: pass a product to obtain the seller behind it. However, it never states when to prefer this over run_flipkart_product, run_flipkart_product_search, or other marketplace seller tools, and gives no prerequisites. Adequate but with clear gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the France registry (RNE / INPI) by registration number or registry URL: name, status, registration date, address and legal form. Flat 30 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Registration number or registry URL. e.g. 552032534 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose a valuable behavioral trait in the cost model ('Flat 30 points per successful run'), which structured fields don't convey. It does not cover behavior on invalid/unknown registration numbers, error or empty-result handling, or whether repeated lookups are cached.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler: identity and return fields first, the unusual cost caveat second. Nothing is buried and nothing is repeated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description usefully enumerates the returned attributes (name, status, registration date, address, legal form), which is exactly the gap it needs to fill. With one fully documented parameter and a stated cost model, an agent has enough to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents the single 'company' parameter, including an example ('552032534'). The description restates the accepted formats (registration number or registry URL) without adding new syntax, validation rules, or fallback behavior. Baseline 3 applies when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get one company'), the exact resource and jurisdiction (France registry, RNE / INPI), the input form (registration number or registry URL), and the field set returned. This cleanly separates it from the sibling run_fr_companies_search, which takes no single-identifier lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies you must already hold an identifier (registration number or registry URL), which is a meaningful usage constraint for this tool versus a name search. However, it never explicitly names run_fr_companies_search as the alternative when you only have a company name, which is the single most likely misuse given ~200 sibling lookup tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the France company registry (RNE / INPI) by company name: name, registration number, status, address and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Company name. e.g. danone | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It usefully discloses the upstream source (RNE / INPI) and a per-record credit cost, but says nothing about permissions, rate limits, or pagination behavior beyond what the schema implies. Adequate but incomplete for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight clauses with zero filler: the core action and source come first, followed by the returned fields and cost. Every element earns its place and nothing is buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates well by enumerating the returned fields (name, registration number, status, address, link) and the cost model. Parameters are fully covered by the schema. Minor gap: no note on result volume or how max_items/start_page interact with the point cost.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with an enum on status, so the schema already documents all four parameters including the required 'keyword'. The description only restates that lookup is by company name, adding no format or syntax detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) plus a precisely named resource (France company registry, RNE / INPI) and the lookup key (company name). This clearly separates it from the sibling run_fr_companies, which is the detail-by-id counterpart, and from other country search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by company name' implies when the tool is applicable and the cost line ('1 point per returned record') is a useful usage consideration. However, no explicit when-to-use vs when-not guidance and no alternative is named (e.g. run_fr_companies for a known registration number), leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AI tool categories of Futurepedia with the number of tools in each and the group they belong to (the top sub-categories shown on the Futurepedia categories page). Optional group filter. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | Group. Options: productivity = AI Productivity Tools, video = AI Video Tools, text-generators = AI Text Generators, business = AI Business Tools, image = AI Image Tools, automations = Automation Tools, art = AI Art Generators, audio-generators = AI Audio Generators, misc-tools = Misc AI Tools, code = AI Code Tools |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose a genuine behavioral trait absent from structured fields ('Flat 5 points per successful run'), which is useful cost context, and it states what data comes back. It says nothing about read-only nature, auth, rate limits, or pagination, so the safety profile remains undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences with the returned data front-loaded, followed by the optional filter and the cost note. Every sentence carries information; the parenthetical about the categories page is slightly wordy but adds provenance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description usefully compensates by describing the return shape (categories, tool counts, groups). For a single optional-enum-parameter listing tool this is nearly complete; only the safety/pagination profile is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single group parameter is fully enumerated with human-readable labels, so the schema does the heavy lifting. The description adds only that the filter is optional, which is marginal value beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (Futurepedia AI tool categories) and specifies the payload: each category with its tool count and group. It reads clearly as a listing operation, distinct from run_futurepedia_tools. It stops short of explicitly naming the sibling it differs from, so it is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Optional group filter' implies you may call it with no arguments to get all categories or with a group to narrow the result, which is adequate implied usage. It gives no guidance on when to prefer this over run_producthunt_categories, run_capterra_categories, or run_futurepedia_tools, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one AI tool from Futurepedia by slug or URL: description, rating and review count, categories, pricing, key features, pros and cons, use cases, pricing plans, rating breakdown and social links. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | Tool slug or Futurepedia URL. e.g. midjourney |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: 'Get' implies a non-destructive read, it enumerates the returned fields, and it uniquely discloses cost ('Flat 5 points per successful run'). It omits auth requirements, rate limits, and error behavior, keeping it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with the verb and scope first, followed by the return inventory and the cost note. The long field enumeration is dense but earns its place since there is no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Because no output schema exists, listing the returned fields is genuinely valuable, and the cost disclosure is included. It is complete for a single-identifier lookup, with only auth/error context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is fully documented in the schema. The description only restates 'by slug or URL' without adding format or normalization detail, so the baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one AI tool from Futurepedia') and pins the input to 'by slug or URL'. It implicitly contrasts with the sibling run_futurepedia_tools_search ('one' by identifier vs. a search), though it never names that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'by slug or URL' implies you must already have a known identifier, which is a form of usage guidance, but the description never states when to use this versus run_futurepedia_tools_search, run_futurepedia_tools_reviews, or run_futurepedia_tools_alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alternatives to one Futurepedia AI tool (slug or URL): name, description, pricing, rating, categories and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | Tool slug or Futurepedia URL. e.g. midjourney | |
| max_items | No | Max items (up to 8) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the cost model (1 point per record) and the returned fields, which is context beyond the schema, but says nothing about error behavior for a bad slug, rate limits, or whether results are cached or paginated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact statements with zero filler; the core purpose is front-loaded and the cost note is a useful trailing detail. Slightly terse but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool with no output schema, listing the returned fields is a genuine contribution. However, the absence of any usage context versus sibling alternative-finders leaves the definition only minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented in the schema. The description mentions 'slug or URL' but adds no format or syntax meaning beyond what the schema's own example ('midjourney') provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (returns alternatives) and resource (one Futurepedia AI tool), and even enumerates the returned fields. It distinguishes itself from run_futurepedia_tools and run_futurepedia_tools_reviews by the 'alternatives' scope, though it never explicitly names those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no exclusions, and no named alternative tool. The '1 point per returned record' note is a cost signal, not usage guidance, so the agent must infer the appropriate context on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
User reviews of one Futurepedia AI tool (slug or URL): rating, review text and reviewer name. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | Tool slug or Futurepedia URL. e.g. midjourney | |
| max_items | No | Max items (up to 250) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the pricing model ('1 point per returned record') and the shape of returned data, which is more than most siblings offer. However, it says nothing about pagination behavior, rate limits, or what happens when a slug/URL is invalid, so gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short clauses: the resource/return-shape statement first, then the cost note. Zero filler and the most decision-relevant information (what you get, what it costs) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description compensates by naming the returned fields, and it flags the per-record billing. The remaining gap is pagination/iteration guidance for pulling reviews beyond a single call, which would matter given the 250-item cap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented by the schema, including the slug/URL format and the 250-item cap. The description only echoes the slug-or-URL input, adding no syntax or format meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: it fetches user reviews of one Futurepedia AI tool, and enumerates the returned fields (rating, review text, reviewer name). It is clear about scope, but does not differentiate itself from near-identical siblings such as run_theresanaiforthat_tools_reviews or other review endpoints in the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description never says when to use this instead of run_futurepedia_tools_search, run_futurepedia_tools, or run_theresanaiforthat_tools_reviews. Usage is only implied by the resource name, leaving the agent to guess based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the AI tools of one Futurepedia category (slug like video-generators or a category URL) with sorting, pricing, feature and verified filters: name, description, pricing, rating, categories and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort. Options: trending = Trending, popular = Popular, new = New | |
| feature | No | Features | |
| pricing | No | Pricing | |
| category | Yes | Category slug or URL. e.g. video-generators | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page | |
| verified_only | No | Verified tools only |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose the returned field set and the billing model ('1 point per returned record'), which is genuinely useful. However, it does not confirm the read-only nature or describe pagination behavior across start_page/max_items, leaving the operational profile partly unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense but efficient sentences with the verb and scope front-loaded; the returned fields and cost note are packed in without filler. Slightly run-on, but every clause carries usable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With seven parameters, no annotations, and no output schema, the description compensates by enumerating the return fields and the cost model. What remains missing is pagination/limits behavior and any guidance on page iteration, which matters given start_page and max_items.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents every parameter including the enum values. The description's 'sorting, pricing, feature and verified filters' merely restates parameter names and the slug/URL example duplicates the schema's own description. Baseline 3 is appropriate when the schema does the heavy lifting and the description adds no syntax or format detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Starts with a specific verb and resource: 'List the AI tools of one Futurepedia category,' and the parenthetical slug/URL example pins down the identifier format. It is clear what the tool does, but it never distinguishes itself from the sibling run_futurepedia_tools or run_futurepedia_categories, so an agent must infer the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context (browse one category with filters) but gives no explicit when-to-use versus alternatives such as run_futurepedia_tools or run_futurepedia_tools_alternatives. In a family with several near-identically named Futurepedia tools, the absence of routing guidance is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full Gartner Peer Insights category and market taxonomy. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden. It usefully discloses cost ('Flat 5 points per successful run') and implies a read-only lookup of the full taxonomy, but says nothing about permissions, pagination, or the shape of what comes back.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler; the purpose comes first and the cost note follows. Efficient, though the cost sentence is tangential to selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter taxonomy lookup with no output schema, the description should indicate what the returned taxonomy looks like (list of category/market names and IDs) so an agent knows how to consume it. That return-shape detail is missing, leaving a meaningful gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, which is the baseline-4 case. Schema coverage is reported at 100% and the empty schema is self-explanatory, so no parameter detail is needed from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get') and a specific resource ('Gartner Peer Insights category and market taxonomy'), which distinguishes it from the Gartner siblings that fetch products, vendors, or market searches. It stops short of explicitly contrasting itself with those siblings, so it lands at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to call this versus run_gartner_market, run_gartner_markets_search, or run_gartner_products_search. The likely role of a taxonomy lookup as a prerequisite for category-filtered calls is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Gartner Peer Insights market profile by alias or URL: features, research, and lessons learned. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | Market alias or URL. e.g. data-loss-prevention |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds real value by disclosing the cost model ('Flat 5 points per successful run') and the shape of the returned content, but says nothing about auth, rate limits, or failure behavior for an invalid alias.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the resource and followed by the cost note. Nothing is redundant, though the return-content list is slightly compressed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with full schema coverage and no output schema, the description covers what the tool fetches and what a run costs. The main omission is sibling differentiation, not callability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'market' parameter, so the schema already documents alias/URL and even gives an example. The description repeats the alias-or-URL notion without adding syntax or fallback details, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get a Gartner Peer Insights market profile') and enumerates the returned content (features, research, lessons learned). However, it does not distinguish itself from close siblings like run_gartner_market_products or run_gartner_markets_search, which an agent must infer from names alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'by alias or URL' phrasing hints at input form but gives no when-to-use guidance, no exclusion of the sibling market/product tools, and no precondition for choosing this over run_gartner_markets_search. Usage must be inferred entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List ranked Gartner Peer Insights products within a market, with ratings and vendors. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | Market alias or URL. e.g. data-loss-prevention | |
| max_items | No | Max items (up to 250) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses the billing behavior ('1 point per returned record') and that it is a read-style listing with ratings/vendors, but omits auth needs, rate limits, and any pagination/ordering behavior beyond 'ranked'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the operation and followed by the cost note. Zero filler; every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter list tool with no annotations and no output schema, the description covers what is returned (products, ratings, vendors) and the billing model. It could say more about result structure or pagination, but it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 both 'market' (with an example alias) and 'max_items' (range up to 250). The description adds no parameter syntax or constraint detail beyond restating the market scoping, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (ranked Gartner Peer Insights products within a market) plus the returned fields (ratings and vendors). It clearly describes the operation, though it does not name the sibling run_gartner_products_search or otherwise distinguish itself from the search variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'within a market', giving an agent a hint that a market alias is the entry point, but there is no explicit when-to-use guidance, no exclusions, and no mention of how this differs from run_gartner_products_search or run_gartner_market.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Gartner Peer Insights markets (software categories) by keyword. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term. e.g. data loss prevention | |
| max_items | No | Max items (up to 250) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the cost model ('1 point per returned record'), but it does not state that the operation is read-only, describe the return format, or mention pagination beyond the schema's max_items.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no waste, and the core purpose is front-loaded. It communicates the action and cost model efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter search tool with full schema coverage, the description is mostly complete: it names the resource and cost model. It could be stronger by clarifying how results differ from run_gartner_categories or run_gartner_market, but no output schema means return values need not be explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the query and max_items parameters are already documented in the schema. The description adds that the search is by keyword but does not elaborate on parameter semantics beyond that baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Search Gartner Peer Insights markets (software categories) by keyword.' This clearly identifies the operation. However, it does not explicitly distinguish this tool from sibling tools like run_gartner_categories or run_gartner_market, leaving some ambiguity about when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives such as run_gartner_categories or run_gartner_market. It implies a keyword search but provides no exclusions, prerequisites, or routing advice among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full Gartner Peer Insights product details by alias or URL: vendor, ratings, and company profile. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product alias or URL. e.g. forcepoint-dlp |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It helpfully discloses the cost model ('Flat 5 points per successful run') and the returned fields, but omits any mention of auth requirements, rate limits, or failure behavior for an invalid alias.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the payload description and followed by the cost note. Nothing is redundant, though the pricing sentence is the only piece of behavioral value beyond the return summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description compensates reasonably by naming the returned data (vendor, ratings, company profile) and the cost. Auth, error handling, and coverage limits remain unstated for a single-record fetch.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'product' parameter is fully documented with an example in the schema. The description only restates 'alias or URL', adding no syntax or format meaning beyond the structured field, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get) and resource (Gartner Peer Insights product details), specifies the identifier form (alias or URL), and enumerates the payload (vendor, ratings, company profile). It is clearly distinguishable from the sibling run_gartner_products_search, which is the search counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance and no named alternative. The 'by alias or URL' phrasing implies an identifier is required but does not explain when to reach for this rather than the product search or vendor tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Gartner Peer Insights products by keyword: name, vendor, and review count. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term. e.g. salesforce | |
| max_items | No | Max items (up to 250) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It usefully discloses '1 point per returned record' as a cost signal, but does not mention pagination behavior, rate limits, permissions, or the full result shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with purpose and cost, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity two-parameter search tool with no output schema, the description plus schema covers inputs, keyword scope, and cost. Missing pagination/rate-limit details are minor, though behavioral transparency remains somewhat thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents query and max_items. The description adds only that the query is a keyword and mentions result fields, without adding search syntax or filtering semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search) and resource (Gartner Peer Insights products) scoped by keyword, and names the result fields. It is clearly distinguishable from siblings in practice, though it does not explicitly contrast with run_gartner_product or run_gartner_market_products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'Search ... by keyword,' but the description gives no explicit when-to-use/when-not guidance and does not name alternatives such as run_gartner_product for a single product lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Gartner Peer Insights vendor profile by alias or URL: markets, products, and ratings. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| vendor | Yes | Vendor alias or URL. e.g. forcepoint |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It usefully discloses a flat 5-point cost per successful run, but does not describe authentication needs, rate limits, failure behavior, or whether the operation is read-only beyond the implication of 'Get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences: the first front-loads purpose and scope, and the second adds cost information. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter lookup with no output schema, the description covers the core purpose, input form, included data categories, and cost. It does not fully document response structure or error behavior, but the essentials are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single parameter is fully documented in the schema with an example. The description repeats that the vendor can be an alias or URL but adds no further meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get a Gartner Peer Insights vendor profile by alias or URL,' and lists the included data types (markets, products, ratings). It is clear what the tool does, but it does not explicitly differentiate itself from adjacent Gartner tools such as run_gartner_product or run_gartner_market.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention sibling tools, prerequisites, or selection criteria beyond the input being an alias or URL.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Georgia registry (NAPR) by identification code: name, status and legal form. 5 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Identification code or registry URL. e.g. 204854595 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does usefully disclose the cost model ('5 point per returned record'), which is real information an agent planner needs, and 'Get' implies a safe read. However, it says nothing about authentication, rate limits, or what happens when the code is invalid/not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence front-loads the operation, the source registry, the key, and the returned fields, followed by a short cost clause. Minor awkwardness in the fragment '5 point per returned record' costs a point but nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup with no output schema, the description usefully enumerates the return fields (name, status, legal form) and the pricing, which is enough to call it correctly. With no annotations and no output schema, a little more on failure modes and registry coverage would round it out.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is fully documented there, including the alternative 'registry URL' form. The description only repeats 'identification code' and omits the URL option, so it adds no meaning beyond the schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one company from the Georgia registry (NAPR)') plus the lookup key ('by identification code') and the returned fields. The singular 'one company ... by identification code' implicitly separates it from the sibling run_ge_companies_search, but the description never names or references that alternative, so the differentiation is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the agent gathers that it needs an identification code or registry URL in hand to call this. There is no explicit when-to-use guidance, no note on what to do if only a company name is known (i.e. use run_ge_companies_search first), and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Georgia company registry (NAPR) by company name or identification code: name, registration number, status and legal form. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Company name. e.g. თიბისი ბანკი | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the billing model ('1 point per returned record'), which is a genuine behavioral trait, but omits auth requirements, pagination behavior, and what the response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and resource, followed by the result fields and the cost note. Efficient and free of padding, though the cost sentence could be folded more tightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema, the field list partially compensates, but it doesn't clarify pagination or how it differs from run_ge_companies, leaving gaps an agent would need to resolve.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 keyword, status, max_items, and start_page. The description adds only a marginal hint that keyword accepts a name or identification code; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search the Georgia company registry (NAPR)') and lists the returned fields (name, registration number, status, legal form), which is clear. However, it does not distinguish itself from the sibling run_ge_companies, so an agent can't tell which of the Georgia tools to pick from the description alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by company name or identification code' implies how to query, but there is no explicit when-to-use, when-not-to-use, or alternative routing (especially versus run_ge_companies). Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one LEI record from the Global LEI Index by LEI code or search.gleif.org link, with the Current Data tab of the page: names, legal form, registration authority, categories, BIC/ISIN codes, addresses, registration and issuer details, fund and branch relationships, and direct and ultimate parents. 5 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | LEI or search.gleif.org link. e.g. HWUPKR0MPOU8FGXBT394 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the load and does it reasonably well: it names the source page ('Current Data tab') and enumerates exactly what comes back (names, legal form, registration authority, BIC/ISIN, addresses, parents), plus the notable '5 point per returned record' cost. It omits failure behavior for an invalid or malformed LEI, which is the main remaining gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and input, then the payload. The returned-field list is long but each item is informative; the trailing cost note is short and useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so enumerating the returned fields is the right compensation, and the single required parameter is fully documented. Missing only error/empty-result behavior for a bad LEI, which keeps it short of a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema itself already documents the single `company` parameter with an example LEI, so the description's 'LEI code or search.gleif.org link' restates rather than extends it. Baseline 3 applies; no format constraints or edge cases are added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one LEI record from the Global LEI Index') and pins the input shape ('by LEI code or search.gleif.org link'), which cleanly separates it from run_gleif_companies_search and run_lei_lookup_companies in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrasing 'one LEI record ... by LEI code or link' implies this is the single-record lookup you use when you already hold an identifier, but it never says so explicitly nor points to the search sibling for name-based discovery. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Global LEI Index by company name or LEI code: LEI, name, LEI status, address, legal form code, creation date, category, jurisdiction, registration dates and managing issuer. Filter by active or inactive LEI, exact LEI status, entity category and country. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Active or inactive LEI. Options: active = Active, inactive = Inactive / dissolved | |
| country | No | Country (2-letter code). e.g. DE | |
| keyword | Yes | Company name or LEI. e.g. Apple | |
| category | No | Entity category. Options: GENERAL = General, FUND = Fund, BRANCH = Branch, SOLE_PROPRIETOR = Sole proprietor, INTERNATIONAL_ORGANIZATION = International organization, RESPONSIBLE_ENTITY = Responsible entity | |
| max_items | No | Max items (up to 250) | |
| reg_status | No | LEI status (exact). Options: ISSUED = Issued, LAPSED = Lapsed, ANNULLED = Annulled, RETIRED = Retired, MERGED = Merged, DUPLICATE = Duplicate, PENDING_TRANSFER = Pending transfer, PENDING_ARCHIVAL = Pending archival, PENDING_NAME_TRANSFER = Pending name transfer, PENDING_NAME_TRANSFER_MERGER = Pending name transfer (merger), PENDING_VALIDATION = Pending validation | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries more of the burden, and it does add the useful '1 point per returned record' cost signal plus a full field enumeration. It still omits permission requirements, pagination behavior, and how results are ordered or truncated, which matters for a search endpoint that can return up to 250 items.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is front-loaded with the search target before the field and filter lists, and both sentences are dense with substance. The middle run-on list of returned fields is a little unwieldy but every item is legitimate information given there is no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Because there is no output schema, the enumeration of returnable fields is doing real work and largely compensates. Combined with the filter and cost notes, an agent has enough to invoke it correctly; only sibling disambiguation and pagination detail are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and three parameters carry enums with their own inline option mappings, so the schema already does the parameter work. The description only echoes the filter categories at a high level and adds no syntax or format detail beyond what the schema provides, which is the baseline 3 case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Search the Global LEI Index by company name or LEI code') and enumerates the returned fields, so an agent knows exactly what this tool retrieves. It does not, however, distinguish itself from close siblings like run_gleif_companies or run_lei_lookup_companies_search, leaving the agent to infer the difference from the name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage by describing the available filter axes (active/inactive LEI, exact LEI status, entity category, country), which signals what queries are supported. But there is no explicit when-to-use / when-not-to-use guidance and no routing to the sibling tools that also surface LEI data, so the agent must infer which one to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Hepsiburada category tree for a category id or URL: the path from the top-level department down to the category, with its nested children (id, name, alias, level, url). Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Category ID or URL. e.g. 371965 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose useful non-schema behavior: the returned field set (id, name, alias, level, url), the nesting/child structure, and a flat 5-credit cost per successful run. It says nothing about permissions, rate limits, or error cases, so the burden is only partly met.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence: the action and resource come first, then the return shape, then the cost note. Every clause is informative; the parenthetical field list is the only part that could be trimmed if an output schema existed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description does the work of describing the return structure (path plus nested children and their fields) and the cost. It lacks any error/edge-case behavior, but for a single-parameter read tool it is close to complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter already documents 'Category ID or URL. e.g. 371965'. The description restates this ('for a category id or URL') without adding format or constraint detail, so it neither helps nor hurts beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb + resource (get the Hepsiburada category tree) and it spells out exactly what the tree contains: path from top-level department down to category plus nested children. It identifies the platform, which separates it from the many other *_categories tools, but it does not explicitly distinguish itself from its closest sibling run_hepsiburada_categories_products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance; the only implicit signal is the 'for a category id or URL' input framing. It never tells the agent to prefer this over run_hepsiburada_categories_products when the goal is browsing the taxonomy versus listing products.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List products in a Hepsiburada category with filters (brand, seller, color, price range, minimum rating, fast delivery, discounted, photo reviews, authorized sellers) and sorting. Returns id, name, brand, price, list price, discount, image, rating and seller. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: artanfiyat = Price: low to high, azalanfiyat = Price: high to low, coksatan = Best sellers, yorumsayisi = Most reviewed, degerlendirmepuani = Top rated, indirimurunler = Biggest discount, enyeni = Newest | |
| brand | No | Brand (slug). e.g. apple, samsung | |
| color | No | Color. Options: Siyah = Siyah, Beyaz = Beyaz, Mavi = Mavi, Lacivert = Lacivert, Mor = Mor, Kırmızı = Kırmızı, Yeşil = Yeşil, Sarı = Sarı, Pembe = Pembe, Gri = Gri, Gümüş = Gümüş, Kahverengi = Kahverengi, Turuncu = Turuncu, Bej = Bej, Krem = Krem, Altın = Altın, CokRenk = CokRenk | |
| category | Yes | Category ID or URL. e.g. 371965 | |
| merchant | No | Seller name (exact, case sensitive). e.g. Hepsiburada | |
| max_items | No | Max items (up to 500) | |
| price_max | No | Max price (TRY) | |
| price_min | No | Min price (TRY) | |
| rating_min | No | Minimum rating. Options: 4.5-max = 4.5 and up, 4-max = 4 and up, 3-max = 3 and up | |
| start_page | No | Starting page | |
| product_type | No | Main category code. e.g. 98 (laptops) | |
| fast_delivery | No | Fast delivery | |
| discounted_only | No | Discounted only | |
| authorized_seller | No | Authorized sellers | |
| recently_reviewed | No | Recently reviewed (last 10 days) | |
| advantageous_price | No | Advantageous price | |
| with_photo_reviews | No | With photo reviews |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the return fields and the cost model ('1 point per returned record'), but omits auth requirements, read-only status, pagination behavior, and rate limits. This is enough to be minimally informative but leaves meaningful behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly written sentences, front-loaded with the purpose, followed by return fields and cost. Every sentence earns its place, and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 17-parameter tool with no annotations and no output schema, the description supplies the action, return shape, and cost. However, it omits usage guidance against sibling tools and does not clarify pagination or limits, leaving gaps that matter for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents every parameter with descriptions and enums. The description lists filter categories and sorting, but adds no syntax, defaults, or format details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List products in a Hepsiburada category with filters ... and sorting.' The required 'category' parameter reinforces the category-scoped purpose. It implicitly distinguishes itself from generic product search tools, but does not name any sibling (e.g., run_hepsiburada_products_search) or explicitly state the boundary between them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no alternatives, and no prerequisites beyond what the name and schema imply. The description enumerates filters and sorting but never says when this category tool should be chosen over the many sibling product tools, nor does it warn about any conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Hepsiburada merchant (store) by slug or store URL: id, name, alias, url and number of products. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| merchant | Yes | Merchant slug or store URL. e.g. efeturk |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It usefully discloses the returned fields and a flat 5-point cost per successful run, but does not cover failure behavior, URL format constraints, or rate-limit/auth considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences with the core lookup behavior front-loaded. The returned fields and pricing note are useful and not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter lookup with full schema coverage and no output schema, the description gives enough context: it names the resource, input forms, returned fields, and cost. It could be more complete with error-case or URL-format notes, but nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already documents the single parameter as a merchant slug or store URL with an example. The description repeats that input form but adds no syntax or validation details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb and resource: "Get a Hepsiburada merchant (store)". It also lists the exact fields returned and distinguishes the singular merchant lookup from siblings like run_hepsiburada_merchants_products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States the accepted input forms (slug or store URL), which implies when to use it, but gives no explicit guidance on when to choose it over related tools such as run_hepsiburada_merchants_products or run_hepsiburada_products_sellers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List products sold by a Hepsiburada merchant with filters (brand, color, price range, minimum rating, fast delivery, discounted, photo reviews) and sorting. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: artanfiyat = Price: low to high, azalanfiyat = Price: high to low, coksatan = Best sellers, yorumsayisi = Most reviewed, degerlendirmepuani = Top rated, indirimurunler = Biggest discount, enyeni = Newest | |
| brand | No | Brand (slug). e.g. apple, samsung | |
| color | No | Color. Options: Siyah = Siyah, Beyaz = Beyaz, Mavi = Mavi, Lacivert = Lacivert, Mor = Mor, Kırmızı = Kırmızı, Yeşil = Yeşil, Sarı = Sarı, Pembe = Pembe, Gri = Gri, Gümüş = Gümüş, Kahverengi = Kahverengi, Turuncu = Turuncu, Bej = Bej, Krem = Krem, Altın = Altın, CokRenk = CokRenk | |
| merchant | Yes | Merchant slug or store URL. e.g. efeturk | |
| max_items | No | Max items (up to 500) | |
| price_max | No | Max price (TRY) | |
| price_min | No | Min price (TRY) | |
| rating_min | No | Minimum rating. Options: 4.5-max = 4.5 and up, 4-max = 4 and up, 3-max = 3 and up | |
| start_page | No | Starting page | |
| product_type | No | Main category code. e.g. 98 (laptops) | |
| fast_delivery | No | Fast delivery | |
| discounted_only | No | Discounted only | |
| authorized_seller | No | Authorized sellers | |
| recently_reviewed | No | Recently reviewed (last 10 days) | |
| advantageous_price | No | Advantageous price | |
| with_photo_reviews | No | With photo reviews |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. 'List' implies a read operation and the '1 point per returned record' clause usefully discloses the credit cost of the call, which is real behavioral value. However, it says nothing about pagination limits, rate limits, or return shape, leaving meaningful gaps for a 16-param read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and facets, then the credit cost. No filler. Slightly dense enumeration of facets, but every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 16-parameter read tool with no annotations and no output schema, the description covers purpose and cost but omits return format, pagination behavior, and any indication of what filters combine well. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented in the schema (including enum expansions and examples). The description only restates a subset of the filter facets (brand, color, price range, rating, delivery, discount, photo reviews) without adding syntax or format detail, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource+scope: listing products sold by a named Hepsiburada merchant, plus the available filter and sort facets. The merchant-scoped framing implicitly distinguishes it from keyword-based siblings like run_hepsiburada_products_search, but it never names an alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the merchant-scoped purpose (fetch a given store's catalog), but there is no explicit when-to-use, when-not, or routing to siblings such as run_hepsiburada_products_search or run_hepsiburada_products. The agent must infer the selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full Hepsiburada product details by SKU, product group id or URL: name, brand, price, list price, discount, images, video, rating, stock, specs, variants, categories, the winning seller and other sellers. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | SKU, product group ID or URL. e.g. HBCV00004X9ZCK |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose a genuine operational trait beyond structured fields ('Flat 5 points per successful run'), which helps cost planning, but says nothing about auth requirements, rate limits, or failure/pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence carrying the identifier forms, a long return-field enumeration, and the cost note; every clause does work. The field list is somewhat dense but is the tool's main value-add given no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description compensates well by enumerating the returned fields (price, sellers, specs, variants, etc.) and disclosing the per-run cost. It stops short of telling the agent when this tool is preferred over the search sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is fully documented in the schema with an example. The description repeats the accepted identifier forms but adds no syntax or format guidance beyond what the schema already provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get full Hepsiburada product details') and scopes the identifier types accepted (SKU, product group id or URL). This clearly separates it from sibling run_hepsiburada_products_search, which returns listings rather than a single product's full record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The identifier types imply this is the single-product detail lookup versus the sibling search tool, so usage is implied rather than stated. There is no explicit 'use this instead of X when...' guidance or any exclusion for ambiguous identifiers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get customer reviews for a Hepsiburada product (aggregated across its variants): rating, text, author, date, verified purchase, helpful count, per-feature ratings, keywords and photos. Sort by most helpful or most recent. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: MOSTHELPFUL = Most helpful, MOSTRECENT = Most recent | |
| product | Yes | SKU, product group ID or URL. e.g. HBCV00004X9ZCK | |
| max_items | No | Max reviews (up to 490) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does meaningful work: it discloses the aggregation behavior across variants, the breadth of returned fields, and a non-obvious cost model ('1 point per returned record'). It stops short of covering pagination limits or rate limiting, but the delivery model disclosure is genuinely useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the payload contents, with the pricing note last. Slight redundancy in restating the sort enum already in the schema, but no wasted prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description correctly enumerates the returned fields and the cross-variant aggregation, which an agent needs in order to interpret results. Pagination mechanics are left to the schema, and no billing caveats are expanded, but the essentials are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 product, sort, max_items and start_page fully. The description re-states the sort options but adds no syntax, format, or edge-case detail beyond the schema, matching the baseline for a fully-documented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get) and resource (customer reviews for a Hepsiburada product), plus the aggregation scope across variants, which clearly separates it from siblings like run_hepsiburada_products (product data) and run_hepsiburada_products_search (product discovery).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description never says when to choose this over the many sibling review tools (e.g. run_trendyol_products_reviews, run_walmart_product_reviews) or when it is inapplicable. The only selection-ish cue is the sort option, which is a parameter, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Hepsiburada products by keyword with filters (brand, seller, color, price range, minimum rating, fast delivery, discounted, photo reviews, authorized sellers) and sorting. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: artanfiyat = Price: low to high, azalanfiyat = Price: high to low, coksatan = Best sellers, yorumsayisi = Most reviewed, degerlendirmepuani = Top rated, indirimurunler = Biggest discount, enyeni = Newest | |
| brand | No | Brand (slug). e.g. apple, samsung | |
| color | No | Color. Options: Siyah = Siyah, Beyaz = Beyaz, Mavi = Mavi, Lacivert = Lacivert, Mor = Mor, Kırmızı = Kırmızı, Yeşil = Yeşil, Sarı = Sarı, Pembe = Pembe, Gri = Gri, Gümüş = Gümüş, Kahverengi = Kahverengi, Turuncu = Turuncu, Bej = Bej, Krem = Krem, Altın = Altın, CokRenk = CokRenk | |
| keyword | Yes | Search term. e.g. iphone 15 | |
| merchant | No | Seller name (exact, case sensitive). e.g. Hepsiburada | |
| max_items | No | Max items (up to 500) | |
| price_max | No | Max price (TRY) | |
| price_min | No | Min price (TRY) | |
| rating_min | No | Minimum rating. Options: 4.5-max = 4.5 and up, 4-max = 4 and up, 3-max = 3 and up | |
| start_page | No | Starting page | |
| product_type | No | Main category code. e.g. 98 (laptops) | |
| fast_delivery | No | Fast delivery | |
| discounted_only | No | Discounted only | |
| authorized_seller | No | Authorized sellers | |
| recently_reviewed | No | Recently reviewed (last 10 days) | |
| advantageous_price | No | Advantageous price | |
| with_photo_reviews | No | With photo reviews |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds useful cost information ('1 point per returned record') beyond the schema, but does not disclose return format, pagination behavior, rate limits, or whether results are read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core search action and filter/sort capabilities. The cost note is concise and no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high schema coverage, the description is sufficient for invoking the tool correctly: keyword is required in schema and optional filters are summarized. The lack of an output schema means return values are not described, but this is a minor gap for a search endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 17 parameters thoroughly. The description names major filter categories and sorting, but adds no syntax or meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: search Hepsiburada products by keyword. It distinguishes itself from sibling tools like run_hepsiburada_products (likely detail), run_hepsiburada_categories_products (category browsing), and run_hepsiburada_merchants_products (merchant filtering).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by saying it searches by keyword, but it does not explicitly state when to use this tool versus alternatives such as category-based or merchant-based Hepsiburada product tools. No when-not conditions or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all sellers (merchants) offering a Hepsiburada product: seller id, name, price, list price, rating, city, shipping flags and which seller wins the buybox. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | SKU, product group ID or URL. e.g. HBCV00004X9ZCK |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden. It usefully discloses the payload contents and the cost model ('Flat 5 points per successful run'), which is real behavioral context, but says nothing about pagination, rate limits, or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence leading with the verb, followed by a compact field list and a cost note. Dense but every clause contributes; only the field enumeration borders on list-dumping.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly takes on the job of explaining return values, and it does so thoroughly. For a simple single-param listing tool it is nearly complete, missing only pagination/volume expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'product' param is fully documented (SKU, product group ID or URL). The description's mention of 'a Hepsiburada product' reinforces but does not extend the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (sellers/merchants offering a Hepsiburada product) and enumerates the returned fields, so the agent knows exactly what comes back. The 'offering a Hepsiburada product' scoping distinguishes it from sibling run_hepsiburada_merchants, which lists merchants directly rather than per-product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the purpose: fetch the sellers for a given product. However, the description never names the alternative (run_hepsiburada_merchants, run_trendyol_products_sellers) or states when-not-to-use, so routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Croatia registry (Sudski registar) by MBS, OIB or registry link: name, status, registration date, address, legal form, capital, activities, members, supervisory board, representatives, legal relations and the list of filed financial reports. 5 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | MBS, OIB or registry URL. e.g. 010006549 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'Get' signals a read operation, and it usefully discloses both the returned data set and the cost ('5 point per returned record'), which the schema never states. However, it says nothing about behavior on a non-matching or malformed identifier (error vs. empty), which matters for a single-identifier lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action, registry, and identifier types, and the pricing note is compact at the end. The long enumeration of return fields is informative rather than filler, though it makes the single sentence sprawl.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so enumerating the returned fields (name, status, capital, members, representatives, financial reports) is genuinely necessary and present, as is the cost. Only the no-match/error behavior is missing, which is a modest gap for a one-parameter lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter already documents the accepted formats and gives an example ('010006549'). The description restates the same three identifier types, adding no new syntax, format authority, or edge-case guidance beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one company from the Croatia registry (Sudski registar)') and enumerates the returned data fields. The singular 'one company ... by MBS, OIB or registry link' implicitly distinguishes it from the sibling run_hr_companies_search, which takes query terms rather than a single identifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The identifier-based input ('by MBS, OIB or registry link') implies this is a lookup tool rather than a query tool, but the description never names run_hr_companies_search as the alternative for finding a company by name or otherwise states when to prefer one over the other. Usage is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Croatia company registry (Sudski registar) by company name: name, MBS, OIB, status, address, court and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Company name. e.g. podravka | |
| max_items | No | Max items (up to 100) | |
| start_page | No | Starting page (20 companies per page) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the data source (Sudski registar) and the credit cost ('1 point per returned record'), but says nothing about auth requirements, rate limits, or pagination behavior beyond what the schema already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Effectively one sentence plus a short cost note, with the core purpose front-loaded. The trailing enumeration of return fields is slightly run-on but earns its place since there is no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-param search tool with no output schema and no annotations, it covers purpose, source, cost and returned fields adequately. Remaining gaps (pagination guidance, auth) are minor since the schema documents paging parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 keyword, status, max_items and start_page. The description adds no syntax or format detail beyond the schema; the field list it gives refers to return values, not parameters. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (Croatia company registry / Sudski registar) plus the lookup key (company name), and even enumerates the returned fields. This clearly distinguishes it from the sibling detail tool run_hr_companies and from run_hr_company_filings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage condition ('by company name') but never says when to use this versus the sibling run_hr_companies lookup or run_hr_company_filings, nor any exclusions. No prerequisites or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the announcements (Objave) or the document collection (Zbirka isprava) of one company in the Croatia registry (Sudski registar), newest first: date, type, topic, case number and file link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| list | No | List. Options: announcements = Announcements (Objave), documents = Documents (Zbirka isprava) | |
| company | Yes | MBS, OIB or registry URL. e.g. 010006549 | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page (20 items per page) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does add real behavioral context: the output fields (date, type, topic, case number, file link), the sort order (newest first), and the cost model (1 point per returned record). It omits auth/permission requirements and pagination behavior, but the cost and ordering disclosures are genuinely beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the core verb+resource, followed by return fields and cost. Every clause earns its place, though the parenthetical native-language glosses add minor length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description usefully enumerates the returned fields and the sort order to compensate. It is largely complete for an agent to call it, missing only pagination notes (which the schema's start_page/20-per-page covers) and auth context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (list, company, max_items, start_page) are already documented in the schema. The description's mention of 'announcements or document collection' and 'one company' simply restates the schema's list and company semantics without adding syntax or format detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (announcements/Objave or document collection/Zbirka isprava of one company in the Croatia Sudski registar). This clearly distinguishes it from the many sibling company-lookup tools like run_hr_companies and run_hr_companies_search, which return company records rather than filings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The presence of the 'list' parameter and its two enum values is explained, implying when each list variant applies. However, there is no explicit guidance on when to prefer this tool over run_hr_companies / run_hr_companies_search, nor any prerequisites for the company identifier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Israel registry (Corporations Authority) by company number: Hebrew and English name, status, registration date, address, company type, liability, purpose and last annual report year. 5 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Company number (מספר חברה). e.g. 520013954 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the full burden and largely meets it: it enumerates the returned fields (Hebrew/English name, status, registration date, address, type, liability, purpose, last annual report year) and discloses the cost ('5 point per returned record'). It omits auth/rate-limit/error behavior, but the return-shape and pricing disclosure is genuinely useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and scope, with return fields and pricing following. Tight and mostly waste-free, though the pricing sentence reads slightly like a footnote.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, no-output-schema lookup, the description does the necessary work by listing the fields returned instead of leaving the agent to guess. Missing only the distinction from run_il_companies_search and any failure-mode context, which are minor for this tool shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single parameter is documented with a Hebrew label and example ('520013954'). The description only repeats 'by company number' and adds no format, validation, or ambiguity guidance beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Get one company from the Israel registry (Corporations Authority) by company number.' The 'one company ... by company number' framing contrasts cleanly with the sibling run_il_companies_search, and it enumerates the returned fields, so an agent can tell exactly what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'by company number' phrasing implies the usage condition (call it when you already have a company number rather than a query string), but it never names run_il_companies_search as the alternative or states when not to use it. Usage is inferable rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Israel company registry (Corporations Authority) by company name or company number: name, registration number, status, address, company type and registration date. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Company name or number. e.g. טבע תעשיות | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the cost model ('1 point per returned record'), which is real behavioral context, but it omits pagination semantics, result-return behavior, and any auth/permission notes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the search target and keys come first, the returned field list and the point cost follow. Nothing is padded or redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description does well to enumerate the returned fields (name, registration number, status, address, company type, registration date) and the point cost. It could still clarify pagination behavior and the boundary with run_il_companies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters (keyword, status enum, max_items, start_page) are already documented. The description only restates the keyword input ('name or company number') and adds no new parameter semantics, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Search the Israel company registry (Corporations Authority)') and the search key ('by company name or company number'), plus the fields returned. It does not explicitly distinguish itself from the sibling run_il_companies, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name and the phrase 'by company name or company number', but there is no explicit when-to-use guidance and no mention of when to prefer the sibling run_il_companies (e.g. exact-number lookup).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Indiegogo campaign by slug or URL: goal, funds raised, backers, phase and outcome, category, tags, story, risks, refund policy, stretch goals, creator and the number of perks. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| campaign | Yes | Campaign slug or URL. e.g. stardome-transparent-suite-pod |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose two non-obvious traits: the exact payload fields returned (goal, funds raised, backers, phase/outcome, story, risks, refund policy, stretch goals, creator, perk count) and the flat 5-point cost per successful run. It still omits error behavior and explicit read-only confirmation, keeping it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then a compact field list and cost note in two sentences with no filler. The long field enumeration is justified because there is no output schema, though it reads as a run-on list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup with no output schema and no annotations, the description compensates well by enumerating the returned fields and the cost. Missing only error/not-found behavior and a pointer to the search sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single 'campaign' parameter is already documented with an example in the schema. The description only restates 'by slug or URL' and adds no format or edge-case detail beyond it, matching the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one Indiegogo campaign') plus the identifier form ('by slug or URL'), which clearly separates it from the search sibling run_indiegogo_campaigns_search. The enumerated return fields further pin down what the call yields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: you need a slug or URL, so the tool fits lookup workflows. It never states when to prefer run_indiegogo_campaigns_search or that a URL/slug is a prerequisite that search can supply. Adequate but with an obvious routing gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Indiegogo (and Gamefound) projects by keyword and category, phase, benefit, tag, creator and player-count filters: name, tagline, goal, funds raised, backers, phase, dates, creator and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: default = Default, newest = Newest, oldest = Oldest, most_popular = Most popular, most_funded = Most funded, alphabetical_asc = Name A-Z, alphabetical_desc = Name Z-A, ending_soon = Ending soon, most_discussed = Most discussed, recent_updates = Recent updates | |
| tags | No | Tags (url-names, comma separated). e.g. kitchen, design | |
| term | No | Keyword. e.g. smart home | |
| phases | No | Phase | |
| benefits | No | Benefits | |
| max_items | No | Max items (up to 250) | |
| categories | No | Categories | |
| creator_id | No | Creator id | |
| start_page | No | Starting page (24 per page) | |
| player_counts | No | Player count (games) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses a real behavioral trait: '1 point per returned record', a cost signal. However, it omits auth requirements, pagination behavior despite the start_page parameter, and whether results span both Indiegogo and Gamefound simultaneously.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the search scope and filters come first, the return fields and point cost follow. The returned-field list is dense but front-loaded and useful given there is no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by listing returned fields (name, tagline, goal, funds raised, backers, phase, dates, creator, link) and the cost model. For a 10-parameter, zero-required search tool this is nearly complete; only sibling routing and pagination behavior are unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 10 parameters with enums and examples. The description restates the filter categories but adds no syntax, format, or interaction detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search Indiegogo (and Gamefound) projects') and enumerates the filter dimensions and returned fields, so the agent knows exactly what the tool retrieves. It does not, however, distinguish itself from the sibling run_indiegogo_campaigns, which likely serves a different access pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the phrase 'by keyword and category, phase, benefit, tag, creator and player-count filters', which tells the agent this is the filtered-search entry point. There is no explicit when-to-use vs run_indiegogo_campaigns or run_kickstarter_projects_search, and no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse the Indie Hackers Ideas database, optionally by category: company, one-line idea, categories and MRR. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Category (Optional). e.g. SaaS | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page (50 ideas per page) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It usefully discloses the credit cost ('1 point per returned record'), which is genuine operational context an agent would not otherwise know. It stops short of describing pagination behavior, result ordering, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence, but the colon-joined list ('...optionally by category: company, one-line idea, categories and MRR') is grammatically confused and forces the reader to disambiguate whether those are filter values or return fields. Front-loaded purpose is good; the tail is not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 0 required params, no output schema, and no annotations, the description is only barely sufficient. It covers the resource, the optional filter, and the credit cost, but leaves returned fields and pagination semantics (beyond the schema) unstated, which is thin for a browse tool in a crowded sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 category, max_items (up to 250), and start_page (50 per page). The description only echoes the optional category filter and adds no format or syntax detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Browse the Indie Hackers Ideas database') that an agent can distinguish from siblings like run_indiehackers_posts_search and run_indiehackers_products_search. However the trailing list 'company, one-line idea, categories and MRR' is grammatically ambiguous about whether it describes the category filter or the returned fields, muddying the purpose somewhat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'optionally by category' implies the filter is discretionary, which is the only usage hint given. There is no guidance on when to use this search variant versus the other Indie Hackers search tools, nor any prerequisite or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Indie Hackers post by its slug or URL: title, full text, author, publish date, upvotes, comment count and the product it belongs to. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| post | Yes | Post slug or Indie Hackers URL. e.g. i-built-a-git-host-where-ai-agents-dont-need-accounts-1dca7d2ac4 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral load; it discloses the returned fields and the flat 5-point cost, which is genuinely useful. It omits error behavior (e.g. invalid slug), any rate or auth constraints, and does not confirm the operation is read-only beyond the verb 'Get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste: purpose and scope first, then the billing note. The field enumeration earns its place because there is no output schema to document the return shape.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup with no output schema, the description compensates well by listing the returned fields and the cost. It is slightly short on failure modes (what happens with a bad slug) but is otherwise sufficient to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already documents that the 'post' parameter accepts a slug or Indie Hackers URL with a concrete example. The description echoes 'slug or URL' but adds no new syntax or format detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one Indie Hackers post by its slug or URL') and enumerates the returned fields, which clearly separates it from the plural/list siblings like run_indiehackers_posts_search. It never names an alternative explicitly, so the differentiation is implied rather than spelled out.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'By its slug or URL' implies this is the right tool only when an identifier is already in hand, and that run_indiehackers_posts_search covers discovery. However, no when-to-use condition or alternative is stated outright, leaving the routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the comments of one Indie Hackers post (threaded: depth and parent id): text, author, upvotes and date. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| post | Yes | Post slug or Indie Hackers URL. e.g. 3-products-0-revenue-i-think-i-finally-understand-the-problem-6509e1a76a | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page (50 comments per page) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does useful work: it discloses threaded structure ("depth and parent id"), returned fields, and a cost signal ("1 point per returned record"). It omits ordering and pagination behavior, but the core read-only listing behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. It delivers purpose, threading context, returned fields, and cost in one compact statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with a fully documented schema, the description is nearly complete: it states the resource, threading structure, return fields, and cost. A minor gap is the lack of explicit ordering or pagination notes, though start_page and max_items are covered by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already defines post, max_items, and start_page, including the 250-item cap and 50-comments-per-page behavior. The description adds little parameter-level meaning beyond what the schema provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: "List the comments of one Indie Hackers post." The resource scope clearly separates it from run_indiehackers_posts and the search sibling, though the description does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for retrieving comments on a single post, but it gives no explicit when-to-use guidance, no exclusions, and no comparison to other Indie Hackers tools such as run_indiehackers_posts or run_indiehackers_posts_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Indie Hackers post feeds: the top posts of a week, month or all time, or the newest posts, with author, upvotes and comment counts. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | A date inside the week or month (YYYY-MM-DD). e.g. 2026-09-02 | |
| sort | No | Sort. Options: top = Top (most upvoted), newest = Newest | |
| period | No | Period (for Top). Options: week = Week, month = Month, all-time = All time | |
| max_items | No | Max items (up to 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It usefully discloses the returned fields (author, upvotes, comment counts) and the pricing model (1 point per returned record), which is genuine cost context. It says nothing about pagination, auth, or how 'top' is ranked beyond upvotes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence that front-loads the resource and the available feed variants. It wastes nothing, though the closing pricing clause is slightly tacked on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four fully documented parameters and no output schema, the minimum an agent needs is present. However, with zero annotation coverage and no output schema, more could be said about the shape of returned records and whether results are paged.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so sort, period, date, and max_items are already fully documented in the schema. The description's mention of periods and sorts merely echoes those enum values without adding format or interaction detail (e.g. how date interacts with period).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (Indie Hackers post feeds) and the variants available (top of week/month/all-time, or newest), plus what each record contains. An agent can tell it apart from run_indiehackers_posts_comments or run_indiehackers_ideas_search, though it never names those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance or exclusions are given. The agent must infer from the name and the mention of 'feeds' that this is for browsing post lists rather than fetching a single post or its comments, and no alternative tool is referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one product from Indie Hackers by slug or URL: name, tagline, description, website, Twitter, self-reported monthly revenue, founders and the product's updates. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product slug or Indie Hackers URL. e.g. mailmeteor |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the returned fields and the fixed cost ("Flat 5 points per successful run"), and "Get" implies a read-only operation, but it says nothing about authentication, rate limits, or what happens when the slug is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence covers the operation, source, input, and return payload, with the cost noted briefly afterward. Dense and waste-free, though the field list runs somewhat long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the field enumeration in the description is doing necessary work, and the cost note adds practical context. It is close to complete for a single-parameter read tool; only auth/error behavior is left unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter is documented with an example, so the baseline is 3. The description adds only that the value may be either a slug or a full Indie Hackers URL, a mild clarification beyond the schema's slug-only example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Get one product from Indie Hackers") plus the accepted identifier forms (slug or URL). The "one product" framing implicitly separates it from the bulk-list sibling run_indiehackers_products_search, though it never names that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: retrieving a known single product by slug/URL. There is no explicit when-to-use vs when-to-use-search guidance, no mention of run_indiehackers_products_search, and no error/not-found prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse the Indie Hackers products directory by sort, category, business model and monthly revenue range: name, tagline and self-reported revenue. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort. Options: recently-updated = Recently updated, recently-added = Recently added, highest-revenue = Revenue: high to low, lowest-revenue = Revenue: low to high | |
| category | No | Category slug. e.g. ai | |
| max_items | No | Max items (up to 18) | |
| business_model | No | Business model. Options: free = Free, ads = Advertising, commission = Affiliate / commission, transactions = Transactional, subscriptions = Subscription-based | |
| monthly_revenue_max | No | Monthly revenue to (USD) | |
| monthly_revenue_min | No | Monthly revenue from (USD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does add genuine behavioral value by disclosing the returned fields and the cost ('1 point per returned record'), but it omits the 18-item cap, pagination behavior, and any auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and filters are front-loaded in one dense sentence, with the cost caveat isolated as a short trailing sentence. No filler, though the single long clause is slightly dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter, fully-optional browse tool with no output schema and no annotations, the description covers purpose, filters, return fields, and cost. It lacks the max-item cap and pagination notes, which is the main remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all six parameters are already documented in the schema. The description restates the filter dimensions and adds the qualifier 'self-reported' for revenue, which adds slight meaning, but otherwise does not enrich the schema's enum explanations or bounds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Browse) and resource (Indie Hackers products directory) plus the exact filter dimensions and returned fields, so an agent knows what it gets. It does not explicitly differentiate itself from the sibling run_indiehackers_products (single-record fetch) or the other indiehackers search tools, which keeps it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use, when-not, or alternative guidance is given. The filter list implies a browse/search pattern, but nothing tells the agent to prefer this over run_indiehackers_products or run_indiehackers_ideas_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Indie Hackers member by username or profile URL: name, bio, products with revenue and the latest activity. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| user | Yes | Username or Indie Hackers profile URL. e.g. uptownhr |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the burden. It usefully discloses the flat 5-point cost per successful run and what the response contains, but says nothing about failure behavior, retries, or rate limits for an unauthenticated scraper-style endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the retrieval and return contents come first, the cost note last. No filler, though the cost sentence could arguably be structured fields rather than prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter, no nested objects, and no output schema, the description's field list (name, bio, products with revenue, latest activity) covers what the agent needs. Minor gap: no mention of lookup failure or whether URL vs username changes behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single param is documented with an example ('uptownhr'). The description restates 'username or profile URL' but adds no syntax guidance beyond the schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one Indie Hackers member') and enumerates the returned fields (bio, products with revenue, latest activity). The word 'one' implicitly distinguishes it from the indiehackers search siblings, but no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: fetch a single member when you already have a username or profile URL. There is no explicit when-to-use vs the *_search siblings or any note about what to do when the identifier is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Kickstarter project by creator/project or URL: goal, pledged, backers, state, dates, creator, category, location, story, risks and counters of rewards, updates, comments and FAQ. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Creator/project or Kickstarter URL. e.g. elanlee/exploding-kittens |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. It usefully discloses the cost model ('Flat 5 points per successful run') and the returned field set, but says nothing about error behavior when a project is not found, authentication, or response shape/pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and input modes, then the returned fields. The long enumeration of fields is dense but informative for a tool with no output schema. No filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup with no output schema, enumerating the return fields is genuinely necessary and is done. The pricing note adds value. Only gaps are error/not-found behavior and the absence of sibling routing, which are minor for a simple fetch.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'project' parameter already documents both accepted formats (creator/project or Kickstarter URL) with an example. The description merely restates 'creator/project or URL', adding no new syntax or format detail. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one Kickstarter project') and enumerates the returned fields (goal, pledged, backers, state, dates, creator, etc.). The word 'one' plus the singular framing distinguishes it from the plural search sibling run_kickstarter_projects_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'Get one Kickstarter project' (single-entity lookup), which a reader can contrast against the search sibling, but the description never names an alternative or states when to prefer it. No explicit when/when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Kickstarter projects by keyword, category, state, staff picks, location and funding ranges: name, blurb, goal, pledged, backers, creator, category and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort. Options: magic = Magic, popularity = Popularity, newest = Newest, end_date = End date, most_funded = Most funded, most_backed = Most backed | |
| term | No | Keyword. e.g. board game | |
| state | No | State. Options: live = Live, successful = Successful, failed = Failed, canceled = Canceled, upcoming = Upcoming | |
| raised | No | Raised. Options: 0 = Less than 75%, 1 = 75% to 100%, 2 = More than 100% | |
| category | No | Category. Options: art = Art, comics = Comics, crafts = Crafts, dance = Dance, design = Design, fashion = Fashion, film-and-video = Film & Video, food = Food, games = Games, journalism = Journalism, music = Music, photography = Photography, publishing = Publishing, technology = Technology, theater = Theater | |
| goal_max | No | Goal max (USD) | |
| goal_min | No | Goal min (USD) | |
| max_items | No | Max items (up to 250) | |
| raised_max | No | Percent funded max | |
| raised_min | No | Percent funded min | |
| start_page | No | Starting page | |
| location_id | No | Location id (woe_id, e.g. 23424977 = USA) | |
| pledged_max | No | Pledged max (USD) | |
| pledged_min | No | Pledged min (USD) | |
| staff_picks | No | Projects We Love (staff picks) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden. It does add genuinely useful behavioral context by disclosing the cost model ('1 point per returned record') and the shape of returned records, but says nothing about pagination, rate limits, or result caps (max_items 250), leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences with no waste. Filter capabilities are front-loaded, followed by returned fields and the cost note, so every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter search tool with no output schema and no annotations, the description compensates by enumerating returned fields and stating cost. However it omits sorting, pagination (start_page/max_items), and raised-vs-state range distinctions, so it is only partially complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 15 parameters, establishing a baseline of 3. The description echoes several filter dimensions (keyword, category, state, staff picks, location, funding ranges) but adds no syntax or format detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Search') and resource ('Kickstarter projects'), then enumerates both the filter dimensions and the returned fields. This clearly distinguishes it as a query tool, but it never references the sibling 'run_kickstarter_projects' to draw the single-vs-search boundary explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The listing of filterable dimensions (keyword, category, state, staff picks, location, funding ranges) implies how the tool is used, but there is no explicit when-to-use guidance, no prerequisites, and no mention of the alternative 'run_kickstarter_projects'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full Kleinanzeigen category tree: id, name, alias, URL and parent id for every department and subcategory. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the returned fields and an explicit cost model ("Flat 5 points per successful run"), which is genuinely useful context, but says nothing about read-only nature, caching, or whether the tree is stable across calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero filler. The resource and its fields are front-loaded, and the cost note follows without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless reference tool with no output schema, stating the returned fields and the point cost covers nearly everything an agent needs. Only the expected use in a category-lookup workflow is left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema has no semantics to cover and the baseline of 4 applies. Nothing in the description misrepresents or adds confusion on this front.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific resource (the full Kleinanzeigen category tree) and enumerates the fields it yields (id, name, alias, URL, parent id). It is distinguishable from siblings like run_kleinanzeigen_listings or run_olx_categories, though it never explicitly contrasts itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no statement that this is a reference lookup whose output feeds category-filtered listing searches, and no named alternative. The agent must infer the purpose of a no-argument tree dump.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Kleinanzeigen ad by id or URL: price, description, location, attributes, images and seller. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| ad | Yes | Ad ID or URL. e.g. 3517031976 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose one real behavioral trait beyond the schema — the flat 5-point cost per successful run — and enumerates the fields returned, but says nothing about auth requirements, rate limits, or failure/not-found behavior for an unannotated read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the core action and the returned fields front-loaded, then the cost note. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, no-annotation, no-output-schema tool the description is nearly sufficient: it names the input forms and summarizes the return payload, standing in for the missing output schema. Only error/edge-case behavior is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'ad' parameter already documents 'Ad ID or URL. e.g. 3517031976'. The description's 'by id or URL' merely repeats the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one Kleinanzeigen ad by id or URL') and enumerates the returned payload (price, description, location, attributes, images, seller). The singular 'one ad by id or URL' clearly separates it from the sibling run_kleinanzeigen_listings_search / _similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the agent infers this is the tool for a known ad ID or URL. Nothing states when to prefer it over run_kleinanzeigen_listings_search (e.g., 'find the ID first with search') or what to do if the listing is gone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search live Kleinanzeigen ads by keyword with category, price, condition, seller type, shipping and sort filters. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: newest = Newest, price_asc = Price: low to high, price_desc = Price: high to low, distance = Distance | |
| buy_now | No | Buy Now only | |
| carrier | No | Carrier. Options: dhl = DHL, hermes = Hermes | |
| keyword | Yes | Search term. e.g. fahrrad | |
| shipping | No | Shipping. Options: shipping = Shipping available, pickup = Pickup only | |
| condition | No | Condition. Options: new_with_tag = New with tag, new = New, like_new = Like new, good = Good, ok = OK, defect = Defective | |
| max_items | No | Max items (up to 500) | |
| max_price | No | Max price (EUR) | |
| min_price | No | Min price (EUR) | |
| offer_type | No | Offer type. Options: offer = Offers (for sale), wanted = Wanted ads | |
| start_page | No | Starting page | |
| category_id | No | Category ID. e.g. 217 | |
| seller_type | No | Seller type. Options: private = Private, commercial = Commercial |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose one valuable trait beyond the schema: '1 point per returned record' cost/pricing. It does not state that this is a read-only operation, nor describe result format, pagination, or row limits beyond the schema's max_items.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the core action and the filter scope, followed by the cost note. No padding or redundant restatement of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter search tool with no output schema and no annotations, the description is adequate but thin: it covers scope and cost while omitting return-shape hints, pagination behavior, and default values. Given full schema coverage for inputs, the remaining gap is moderate rather than severe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and six parameters carry enums with inline option descriptions, so the schema already does the heavy lifting. The description only summarizes the filter families (category, price, condition, seller type, shipping, sort) without adding syntax, formats, or defaults beyond what structured fields provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search live Kleinanzeigen ads by keyword') and enumerates the filter dimensions, so the agent knows exactly what the tool retrieves. It does not, however, distinguish itself from near-name siblings such as run_kleinanzeigen_listings or run_kleinanzeigen_listings_similar, leaving that differentiation to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys what the tool does but gives no when-to-use guidance, no prerequisites, and no routing to alternatives. With siblings like run_kleinanzeigen_listings and run_kleinanzeigen_listings_similar in the toolset, the absence of any disambiguation is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Related ads Kleinanzeigen shows on an ad's page, by ad id or URL. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| ad | Yes | Ad ID or URL. e.g. 3517031976 | |
| max_items | No | Max items (up to 100) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does add one genuinely useful behavioral fact — '1 point per returned record' cost — but says nothing about return shape, whether results are paginated, or how many related ads are typically available, which matters given there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the resource and scope, with the cost note appended last. Nothing is wasted and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter retrieval tool the description covers the source and the cost, which is the minimum viable set. But with no annotations and no output schema, it should say more about what a returned record contains or how pagination behaves.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 ad, max_items, and start_page. The description's 'by ad id or URL' merely restates the schema's own parameter description, adding no new semantics. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: related ads that Kleinanzeigen surfaces on an ad's page, keyed by ad id or URL. This clearly distinguishes it from the generic run_kleinanzeigen_listings_search, but it never names a sibling explicitly, so routing relies on the agent inferring the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'related ads Kleinanzeigen shows on an ad's page' — an agent can infer this is the recommendation/similar-ads lookup rather than a keyword search. However, there is no explicit when-to-use/when-not-to-use statement or named alternative (e.g. use listings_search for keyword discovery instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Kleinanzeigen seller by user id or profile URL: type, active since, followers and badges. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| seller | Yes | Seller user ID or profile URL. e.g. 4667542 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It usefully adds the returned fields (type, active since, followers, badges) and the flat 5-point cost per successful run, but says nothing about auth needs, rate limits, invalid-ID behavior, or failure modes for a network-backed extraction tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with what is fetched, followed by cost. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description partially compensates by naming the returned attributes and the point cost, which is enough for an agent to select and call it correctly. Error behavior and pagination/auth context for a zero-annotation tool remain unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single 'seller' parameter is already documented with an example (4667542). The description repeats 'user id or profile URL' without adding format or validation detail beyond the schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('Get one Kleinanzeigen seller') plus the two accepted identifiers (user id or profile URL), which implicitly contrasts with sibling run_kleinanzeigen_sellers_listings. It never names that sibling explicitly, so it falls short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is strongly implied: fetch a single seller profile when you have an ID or URL. However there is no explicit when-to-use/when-not guidance and no mention of the sibling _sellers_listings tool for fetching a seller's listings, leaving the agent to infer the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A seller's active Kleinanzeigen ads by user id or profile URL. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| seller | Yes | Seller user ID or profile URL. e.g. 4667542 | |
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It usefully discloses that only *active* ads are returned and that cost is 1 point per record, but says nothing about pagination behavior, ordering, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler, the resource and keying options front-loaded, and the credit cost relegated to a trailing clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter list tool with a fully documented schema and no output schema, the description covers what is needed: what is returned (active ads), how it is keyed, and the cost. Missing only pagination/ordering hints, which the schema partly handles.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all three parameters are documented in the schema. The description confirms the seller parameter accepts either a user ID or a profile URL, adding marginal value; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: a seller's active Kleinanzeigen ads, keyed by user id or profile URL. It clearly targets a seller's listings rather than a general listing search, though it does not name the sibling (e.g., run_kleinanzeigen_sellers for profile data) it diverges from.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied – the description lets an agent infer this is the tool for 'all ads from one seller' but never states when to prefer it over run_kleinanzeigen_listings_search or run_kleinanzeigen_sellers, nor any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the South Korea registry (DART) by DART corp code, stock code or registry link: name, English name, market, registration numbers, address, industry, established date, representatives, name history and representative history. 15 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | DART corp code, stock code or registry URL. e.g. 00126380 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does a decent job: it enumerates the fields returned (name, English name, market, registration numbers, address, industry, etc.) and discloses a cost of "15 point per returned record." It does not mention auth requirements or rate limits, but the return profile and pricing are genuinely useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence naming the verb, source, accepted IDs, and returned fields, with cost tacked on efficiently. No filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read lookup with no output schema, the description compensates by listing the returned fields, and the cost note sets expectations. It is nearly complete, missing only occasional-use caveats such as error behavior for invalid IDs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single documented parameter, so the schema already defines the accepted input. The description restates the identifier types but adds no format syntax or examples beyond what the schema provides, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ("Get one company") and resource ("South Korea registry (DART)"), plus the exact identifiers accepted. It implicitly distinguishes itself from the sibling run_kr_companies_search by emphasizing a single-company lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by "one company" and the accepted identifier formats (corp code, stock code, registry link), which suggests a direct-lookup scenario. However, it never explicitly names run_kr_companies_search as the alternative for finding a company you don't yet have an ID for, so routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the South Korea company registry (DART) by company name or stock code: name, DART corp code, market, stock code and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Company name. e.g. 삼성전자 | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose two valuable behavioral facts: the exact fields returned (name, DART corp code, market, stock code, link) and the cost model ('1 point per returned record'). However, it says nothing about authentication, rate limits, or how pagination/start_page behaves, leaving notable gaps for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tightly-packed sentence front-loads the resource and lookup keys, then lists return fields and pricing. Nothing is wasted, though the return-field list is slightly dense inline.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no annotations and no output schema, the description covers the registry, the accepted input keys, the returned fields, and the cost, which is close to what an agent needs. Only pagination semantics and any rate/auth constraints remain unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 keyword, max_items, and start_page, setting the baseline at 3. The description adds a small amount beyond the schema by noting that the keyword may be a stock code, not just a company name, but does not elaborate on the other two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (South Korea company registry / DART) plus the lookup keys (company name or stock code), which is clearly distinguishable from siblings like run_kr_company_filings or run_kr_companies. It does not explicitly contrast itself with the non-search run_kr_companies sibling, so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by company name or stock code' implies when the tool is applicable, but there is no explicit when-to-use/when-not guidance and no named alternative among the many sibling search tools. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the filings of one South Korea company (DART) by DART corp code, stock code or registry link, newest first: report id, report name, filer, filing date, correction flag, remarks and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | DART corp code, stock code or registry URL. e.g. 00126380 | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses sort order (newest first), the returned field set, and cost ('1 point per returned record'). It omits auth/permission requirements, rate limits, and pagination behavior beyond the schema's max_items/start_page.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that leads with the purpose and then lists the identifier options and output fields. Dense but every clause carries information; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by enumerating the returned fields and the sort order, and it flags the per-record cost. Pagination semantics and prerequisite lookup are the only notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented in the schema. The description reinforces the company parameter's accepted identifier forms but adds no syntax or format detail beyond what the schema's example already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (DART filings of one South Korea company), and enumerates the returned fields. An agent can distinguish it from run_kr_companies and run_kr_companies_search without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The accepted identifier formats (DART corp code, stock code or registry link) give practical input guidance, and 'newest first' implies a listing context. However, there is no explicit when-to-use statement and no routing to siblings such as run_kr_companies_search for discovering a corp code.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the leboncoin category tree (id, name, slug, parent and nested subcategories). With include_filters enabled, the first category also carries the full catalog of search filters and their enum values. 5 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Category (optional). e.g. Category id or slug, e.g. 2 or voitures (empty = whole tree) | |
| include_filters | No | Include the search filters catalog (first category) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden, and it does meaningful work: it discloses the shape of the returned tree, that include_filters attaches a filter catalog only to the first category, and the cost ('5 point per returned record'). It omits any auth, rate-limit, or pagination behavior, so it isn't fully complete but is well above the annotation-relief baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose, then the include_filters nuance, then cost. No filler and every sentence adds signal; the final cost sentence is terse but informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly compensates by enumerating the returned fields (id, name, slug, parent, nested subcategories). Both parameters and the cost are covered, leaving only auth/rate-limit details unaddressed, which is a minor gap for a read-only taxonomy tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented, giving a baseline of 3. The description adds minor extra meaning by noting that include_filters attaches the filters (with enum values) to the first category, but the 'empty = whole tree' semantics for category is already in the schema, so the marginal value is small.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: get the leboncoin category tree, and enumerates what it returns (id, name, slug, parent, nested subcategories). It is unambiguous which domain it belongs to, though it never contrasts itself with sibling category tools like run_olx_categories or run_kleinanzeigen_categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance and no named alternative. The agent can infer this is a taxonomy-lookup tool used before searching or filtering listings, but the description never states that or offers exclusions, so it must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a full leboncoin ad by ID (or listing URL): title, description, price (EUR), category, category attributes, images, location, publication and expiry dates, and seller. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| listing | Yes | Ad ID or listing URL. e.g. 3188662248 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the returned payload and the "Flat 5 points per successful run" cost, but it does not state error behavior or whether the operation is strictly read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences: purpose and returned fields are front-loaded, followed by cost. Every clause earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter lookup with no output schema, the description is largely complete: it identifies the required input and enumerates the main response fields. It could mention failure behavior, but the core information an agent needs is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter and schema description coverage is 100%, so the schema already documents the accepted "Ad ID or listing URL" value. The description repeats that input form but adds no extra syntax or format guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: "Get a full leboncoin ad by ID (or listing URL)", then enumerates the returned fields. This makes it clearly a detail-fetch tool rather than a search or seller-listing tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an ad ID or listing URL is available, but it does not name alternatives such as run_search or explain when to use sibling tools like run_leboncoin_listings_similar. Usage is inferable but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the 'annonces similaires' recommended for a leboncoin ad (by ID or URL): title, price, attributes, images, location and seller. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| listing | Yes | Ad ID or listing URL. e.g. 3188662248 | |
| max_items | No | Max items (up to 100) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose one important behavioral trait: '1 point per returned record,' a credit-cost model an agent should know before choosing max_items. It stops short of describing pagination behavior, error handling for invalid/expired ads, or whether recommendations are geo-restricted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the action and target, then lists the payload, followed by the cost note. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description compensates by enumerating the returned fields (title, price, attributes, images, location, seller), and the per-record cost is disclosed. Only edge-case behavior on bad IDs or empty recommendation sets is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented, including the 1–100 bound on max_items and the page semantics of start_page. The description only reinforces that the listing identifier may be an ID or a URL, which is a small addition over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get the annonces similaires recommended for a leboncoin ad'), names the accepted input forms (ID or URL), and enumerates the returned fields. The 'similar/recommended' framing clearly separates it from run_leboncoin_listings or run_leboncoin_sellers without needing the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied clearly — you have a specific ad and want its recommended look-alikes — and 'by ID or URL' tells the agent what it needs to supply. However, no alternatives are named (e.g., vs. run_leboncoin_listings for search) and no prerequisites or failure conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a French place name or postcode into leboncoin location objects: label, city, zipcode, department/region id and coordinates. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Search term. e.g. Bordeaux | |
| max_items | No | Max items (up to 50) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose the cost model ('1 point per returned record') and the shape of returned objects, which is genuinely useful. However, it says nothing about auth requirements, rate limits, or error behavior when a place name cannot be resolved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences with zero filler, front-loaded with the core action and followed by the return shape and cost. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly enumerates the returned fields, and it discloses the point cost. Given the low complexity (3 simple params, no nesting), this is nearly complete; only the absence of failure/precondition guidance keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 three parameters. The description adds modest value by clarifying that the keyword is specifically a place name or postcode, whereas the schema only says 'Search term. e.g. Bordeaux'. This is a small enhancement over the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Resolve') and resource ('French place name or postcode into leboncoin location objects') and enumerates the returned fields. This clearly distinguishes it from sibling tools like run_leboncoin_listings or run_leboncoin_sellers, which retrieve different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'Resolve a French place name or postcode', but there is no explicit when-to-use guidance, no mention that this is typically a prerequisite for location-filtered listing searches, and no named alternatives. The agent must infer the workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a leboncoin professional store by store ID, seller UUID or store URL: name, SIREN/SIRET, activity sector, description, opening hours, website, address, rating, services and team. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| seller | Yes | Store ID, seller UUID or store URL. e.g. 1268824 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses a flat cost per successful run and enumerates returned data fields, but says nothing about authentication needs, rate limits, error behavior, or whether the lookup is read-only beyond the verb 'Get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and identifier options, then adds a concise cost note. Every sentence serves a purpose, and the returned-field list is informative rather than bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter lookup with no output schema, the description compensates by listing the returned fields and noting cost. It is largely complete, though it omits any mention of error conditions or authentication prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 the single 'seller' parameter and its example. The description lists the same three identifier formats as the schema and adds no additional syntax or format guidance beyond what is structured.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Get) and resource (leboncoin professional store) and enumerates the key identifier formats accepted. It clearly distinguishes a single-store lookup from a search-style sibling, though it does not name alternative tools explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The identifier forms (store ID, seller UUID, store URL) imply this is for looking up a store when you already have an identifier, but there is no explicit when-to-use or when-not-to-use guidance relative to run_leboncoin_sellers_search or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the curated customer reviews leboncoin shows for a professional store (author, rating, text, date, source: Google Maps / Opinion System). 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| seller | Yes | Store ID, seller UUID or store URL. e.g. 51895 | |
| max_items | No | Max items (up to 100) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it partially discharges it: it names the review fields returned, attributes the sources (Google Maps / Opinion System), and discloses the billing unit ('1 point per returned record'). However, it says nothing about whether this is a read-only operation, pagination behavior (start_page), rate limits, or whether the review set is exhaustive versus curated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tight, front-loaded prose: the core action and resource come first, followed by returned fields and the billing note, with no filler. Slightly dense parenthetical, but every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so enumerating the returned fields (author, rating, text, date, source) is valuable and largely compensates. Combined with 100% parameter coverage, the definition is nearly complete, though it omits any indication of how start_page/max_items interact or how large a store's review set can be.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 seller, max_items, and start_page including examples and bounds. The description adds context by clarifying that the target is a professional store's reviews but contributes no additional parameter syntax or format detail; baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb ('Get') with a precise resource: curated customer reviews that leboncoin displays for a professional store, and even enumerates the returned fields (author, rating, text, date, source). An agent can distinguish it from run_leboncoin_sellers and run_leboncoin_sellers_search by the resource type, though the description never names those siblings explicitly to sharpen the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what it retrieves but gives no when-to-use guidance, no preconditions for the seller identifier, and no pointer to alternatives such as run_leboncoin_sellers_search for finding a store first. The 'professional store' phrase implies a seller must already exist, but that inference is left entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse leboncoin's professional-stores directory by activity sector: id, name, activity sector, city, department and region. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sector | No | Activity sector. Options: immobilier = Real estate, vehicules = Vehicles, materiel_professionnel = Professional equipment, electronique = Electronics, maison_jardin = Home & garden, mode = Fashion, loisirs = Leisure, locations_de_vacances = Holiday rentals, emploi = Jobs, services = Services | |
| category | No | Category slug. e.g. toutes_categories | |
| max_items | No | Max items (up to 300) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does add real behavioral value by disclosing the cost model ('1 point per returned record') and the shape of returned records, which are not derivable from the schema. It stops short of disclosing pagination behavior, ordering, result limits, or whether an API key/auth is required, which are meaningful gaps for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler; the resource and filter dimension are front-loaded and the cost note is appended. Slightly terse relative to what an unannotated, output-schema-less tool needs, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description usefully enumerates the returned fields (id, name, activity sector, city, department, region) and the cost, which compensates well for the missing output schema. It is still incomplete on pagination semantics and authentication, but the core calling information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the sector enum fully spelled out and max_items (up to 300) and start_page documented in the schema. The description only restates the sector filter and does not clarify how 'category' relates to 'sector' or how max_items/start_page interact for pagination, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Browse leboncoin's professional-stores directory') plus scoping ('by activity sector'), and enumerates the returned fields. An agent can tell it apart from run_leboncoin_sellers_reviews, but it does not explicitly contrast itself with the sibling run_leboncoin_sellers, so the differentiation is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'By activity sector' implies the intended usage context, and the sector enum reinforces it. However, there is no explicit when-to-use guidance, no statement of when this is preferable to run_leboncoin_sellers or run_leboncoin_categories, and no mention of the fact that all four parameters are optional and filtering is therefore optional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Legal Entity Identifier record by LEI code or lei-lookup.com link: name, entity and LEI status, registration and renewal dates, managing issuer, legal form, registration authority, legal and headquarters addresses, parent companies and the number of subsidiaries. 5 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | LEI or lei-lookup.com link. e.g. HWUPKR0MPOU8FGXBT394 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden. It usefully discloses the cost model ('5 point per returned record') and lists the record's fields, which is real behavioral information. However it says nothing about auth requirements, behavior on an invalid/unknown LEI code, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the verb and resource, then a compact field inventory, then the cost note. The field enumeration is long but each item is informative and the second sentence is tight; nothing is clearly wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description steps in by enumerating the returned fields (status, dates, addresses, parent companies, subsidiary count), which is what the agent needs. It is nearly complete for a single-record read, missing only error/invalid-input behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'company' parameter already documents the LEI/link format with an example, so the schema does the heavy lifting. The description restates 'LEI code or lei-lookup.com link' without adding syntax or validation detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one Legal Entity Identifier record') and enumerates the returned fields, which pins down the scope. It implicitly distinguishes itself from run_lei_lookup_companies_search by saying 'one ... record', but never names that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes the accepted input ('LEI code or lei-lookup.com link') which hints at usage, but gives no when-to-use, when-not, or comparison against run_lei_lookup_companies_search or run_lei_lookup_company_relationships. The agent must infer that this is the single-record lookup and the other is the search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the public register of Legal Entity Identifiers by company name or LEI code: LEI, name, country, entity status, LEI registration status and link. Filter by entity status (active or inactive), LEI registration status and country. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Entity status. Options: active = Active, inactive = Inactive / dissolved | |
| country | No | Country (2-letter code). e.g. DE | |
| keyword | Yes | Company name or LEI. e.g. Apple | |
| max_items | No | Max items (up to 250) | |
| reg_status | No | LEI status. Options: ISSUED = Issued, LAPSED = Lapsed, ANNULLED = Annulled, MERGED = Merged, RETIRED = Retired, DUPLICATE = Duplicate, PENDING_TRANSFER = Pending transfer, PENDING_ARCHIVAL = Pending archival | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does add real value by disclosing the cost model ('1 point per returned record') and the exact fields returned, but it omits pagination behavior, auth requirements, and any rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded with purpose, then filters, then cost. Every clause carries information and nothing is wasted, though the return-field list and filter list slightly overlap in intent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully enumerates the returned fields, and with no annotations it supplies the cost note. For a 6-parameter search tool it covers the essentials, though the absence of pagination and auth context leaves minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 keyword, country, max_items, start_page and both enums in detail. The description restates the filter set (active/inactive status, registration status, country) but adds no format or syntax detail beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (public register of Legal Entity Identifiers) and enumerates the returned fields (LEI, name, country, entity status, LEI registration status, link). An agent can distinguish this from the sibling run_lei_lookup_companies (non-search) and other company-search tools without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says the search is driven by company name or LEI code and lists the available filters (entity status, LEI registration status, country), which implies when the tool is useful. However, it never names alternatives such as run_lei_lookup_companies or run_gleif_companies_search, nor states when-not to use it, so routing guidance is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Subsidiaries of one legal entity in the LEI register (direct and ultimate children): LEI, name, type of relationship and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | LEI or lei-lookup.com link. e.g. 7LTWFZYICNSX8D621K86 | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses the return fields and per-record cost, and implies a read-only lookup, but it omits rate limits, permissions/auth requirements, pagination behavior, and error/edge-case behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact clauses that front-load the resource and follow with the returned fields and cost. Every element earns its place; there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter read-only lookup with no output schema and no annotations, the description covers purpose, output fields, and cost. It leaves gaps around sibling selection, pagination semantics (though schema covers max_items/start_page), and operational behavior, so it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already defines company, max_items, and start_page with examples and limits. The description adds only 'one legal entity' for company and does not add syntax, constraints, or defaults beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact resource: subsidiaries/relationships of one legal entity in the LEI register, and specifies direct and ultimate children. It clearly differentiates from the sibling company and company-search tools by focusing on relationship data, though it uses a noun phrase rather than an explicit verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives no explicit when-to-use guidance, no when-not conditions, and never names an alternative such as run_lei_lookup_companies_search or run_gleif_companies. The only implicit guidance is that the tool applies to one legal entity's subsidiaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches LinkedIn employees for one or more companies using people-style filters.
| Name | Required | Description | Default |
|---|---|---|---|
| companies | Yes | ||
| locations | No | ||
| startPage | No | ||
| maxResults | No | ||
| industryIds | No | ||
| scraperMode | No | ||
| searchQuery | No | ||
| pastJobTitle | No | ||
| functionFilter | No | ||
| seniorityLevelFilter | No | ||
| currentJobTitleFilter | No | ||
| companyHeadcountFilter | No | ||
| yearsOfExperienceFilter | No | ||
| yearsAtCurrentCompanyFilter | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the entire burden, yet it discloses nothing about pagination (startPage/maxResults), rate limits, credential requirements, or the scraperMode behavior. 'People-style filters' hints at filter semantics but stops short of describing actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. It is efficient, though its brevity is a symptom of under-specification rather than disciplined conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 14-parameter search tool with no annotations, no output schema, and zero schema coverage, one sentence is far too thin. The agent has insufficient information to select filters or predict results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 14 parameters at 0% schema description coverage, the schema documents nothing. The description only gestures at 'people-style filters' without explaining any of companies, locations, seniorityLevelFilter, functionFilter, yearsOfExperienceFilter, etc., leaving nearly all parameters undefined for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (searches) and resource (LinkedIn employees for one or more companies), so the agent knows this returns employee records. It partially distinguishes itself from run_linkedin_people_search by scoping to companies, but never names or contrasts the sibling directly, so the differentiation is inferential rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance and no named alternative among the many LinkedIn siblings (run_linkedin_people_search, run_linkedin_company_search). The agent must infer usage purely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches LinkedIn companies by query and optional filters.
| Name | Required | Description | Default |
|---|---|---|---|
| maxItems | No | ||
| locations | No | ||
| startPage | No | ||
| companySize | No | ||
| industryIds | No | ||
| scraperMode | No | ||
| searchQuery | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, yet it says nothing about authentication, rate limits, pagination, scraperMode, result ordering, or what happens when filters are omitted. It is not misleading, but it discloses almost no behavior beyond the high-level operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is front-loaded and free of waste, but it is undersized for a seven-parameter tool with zero schema documentation. Conciseness is not the problem; insufficient substance is.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given seven undocumented parameters, no annotations, no output schema, and a complex LinkedIn search domain, one sentence is not complete enough for an agent to invoke the tool correctly. Critical details like pagination, filter formats, and scraperMode behavior are entirely absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across seven parameters, so the description must compensate and does not. It mentions only a query and vague 'optional filters', leaving searchQuery, maxItems, startPage, locations, companySize, industryIds, and scraperMode semantically unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it searches LinkedIn companies, with a query and optional filters. This clearly distinguishes it from people-oriented siblings by resource, though it does not explicitly name alternatives like run_linkedin_people_search or run_linkedin_company_employee.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives no guidance on when to use this tool versus the many sibling search tools, nor any exclusions or prerequisites. The phrase 'optional filters' implies refinement but does not explain when or why to apply them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds a LinkedIn profile by company name or domain and full name.
| Name | Required | Description | Default |
|---|---|---|---|
| full_name | Yes | ||
| company_or_domain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden. It says nothing about authentication requirements, what a matched profile contains, behavior when no profile is found, or rate limits — all material for a lookup tool in a crowded sibling set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence, front-loaded with the verb and resource. No padding or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity (2 params), but with no annotations and no output schema the description should say what 'finds' returns (profile URL, headline, etc.). As written, an agent knows the inputs but not the result shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does clarify that company_or_domain accepts either a company name or a domain, which adds real meaning, but full_name is left to the schema's obvious naming and no format examples are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (Finds) plus resource (LinkedIn profile) and the two lookup keys. Clear on its own, but it never distinguishes itself from closely-named siblings like run_linkedin_people_search or run_linkedin_company_employee, which an agent could easily pick instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance and no mention of alternatives. Given multiple LinkedIn siblings (company_search, people_search, email, company_employee), the agent gets no signal about which situation this tool is for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Looks up a LinkedIn profile and returns contact details, including email when available.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Full LinkedIn profile URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It offers one useful hint ('email when available', signaling non-deterministic coverage), but says nothing about failure behavior on a missing/private profile, auth requirements, or the shape of returned contact details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the verb leading and no padding. It is appropriately sized for a one-parameter lookup, though it could have spent that brevity budget on routing guidance instead.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a trivial one-param lookup with no output schema, the description is minimally sufficient, covering what is fetched. It is missing the failure/empty-result behavior and any sibling routing that would make it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter with 100% schema coverage; the schema already documents that the value must be a full LinkedIn profile URL. The description adds no format or interpretation guidance beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('looks up'), resource ('LinkedIn profile'), and outcome ('returns contact details, including email'). This is a clear purpose, but it never differentiates itself from close siblings like run_linkedin_people_search or run_email_finder that could plausibly return email too.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance and no mention of alternatives, despite siblings such as run_email_finder, run_email_enrichment, and run_linkedin_people_search that overlap in outcome. The agent must guess whether this is the right email-retrieval tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches LinkedIn people using optional query terms and advanced filters.
| Name | Required | Description | Default |
|---|---|---|---|
| lastNames | No | ||
| locations | No | ||
| startPage | No | ||
| firstNames | No | ||
| maxResults | No | ||
| industryIds | No | ||
| pastCompany | No | ||
| scraperMode | No | ||
| searchQuery | No | ||
| pastJobTitle | No | ||
| currentCompany | No | ||
| functionFilter | No | ||
| seniorityLevelFilter | No | ||
| currentJobTitleFilter | No | ||
| companyHeadcountFilter | No | ||
| yearsOfExperienceFilter | No | ||
| yearsAtCurrentCompanyFilter | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure, and it discloses almost nothing. It does not state whether the search is read-only, whether it requires authentication or a paid account, how results are paginated (despite startPage/maxResults), or what scraperMode changes. For a 17-parameter scraping tool this is a substantial gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler or repetition. It is efficient, though the brevity comes at the cost of the detail the rest of the definition lacks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 17 parameters at 0% schema coverage, no annotations, and no output schema, the description is far too thin. An agent has no way to learn filter semantics, result limits, pagination, or return shape from this definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 17 parameters, so the description must compensate and largely does not. Saying 'optional query terms and advanced filters' hints that parameters are optional and filter-shaped, but it names none of the actual filters (locations, seniorityLevelFilter, industryIds, currentCompany, etc.), leaving the agent to guess from raw property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Searches LinkedIn people'. That is clear enough for an agent to know it is a people-search tool rather than a company or email tool. However, it offers no differentiation from close siblings such as run_linkedin_company_employee or run_linkedin_email, and 'advanced filters' is left undefined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The sibling set contains several LinkedIn tools (company_search, company_employee, email, domain), and the description does not state which one to pick under which condition, nor any prerequisite or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Luxembourg registry (LBR / RCS) by RCS number or registry link: name, status (radiée / en faillite), registration and deletion date, address, legal form, trade names, NACE code, and EUID. 5 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | RCS number or registry URL. e.g. B82454 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does useful work: it lists the returned fields, notes that status can be radiée/en faillite, and discloses the '5 point per returned record' cost. It omits auth requirements, rate limits, and not-found/error behavior, leaving meaningful gaps for an unannotated read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the verb and resource, then enumerates return fields and cost in one compact sentence with no filler. Slightly dense with the long field list, but every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup with no annotations and no output schema, the field enumeration effectively stands in for the missing return-value documentation, and cost is disclosed. Only edge behavior (not-found, invalid ID) is unaddressed, a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the single 'company' parameter, its example B82454, and the accepted RCS-number-or-URL formats are already fully documented in the schema. The description restates the accepted formats but adds no syntax or format detail beyond it, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get) and resource (one company from the Luxembourg LBR/RCS registry), and specifies the exact identifiers accepted. The singular 'one company ... by RCS number' clearly separates it from the sibling run_lu_companies_search without needing to name it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'one company ... by RCS number or registry link' framing makes the single-entity, ID-based lookup pattern obvious, contrasting implicitly with the search sibling. It does not, however, explicitly name an alternative or state when-not-to-use, so it stops short of the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Luxembourg company registry (LBR / RCS) by company name or RCS number: name, RCS number, status (radiée / en faillite) and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Company name. e.g. arcelormittal | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses the credit cost ('1 point per returned record') and lists the return fields, but says nothing about pagination behavior, rate limits, or the scale of results beyond the schema's max_items.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence that front-loads the source and search modes, then the outputs and cost. Nothing is redundant, though it could be split slightly for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description compensates by enumerating the returned fields (name, RCS number, status, link). Combined with fully documented params, an agent has enough to call it correctly; only result-volume and pagination semantics are unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds real value by stating the keyword can be an RCS number, which the schema ('Company name') does not, and by giving the French status labels (radiée / en faillite) that map onto the schema's active/inactive enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (Luxembourg company registry LBR/RCS) and enumerates the returned fields, so the agent knows exactly what it gets. It does not differentiate from the sibling run_lu_companies (the non-search variant), which is the only gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'search by company name or RCS number', giving the agent a clear sense of when it applies. However, there is no explicit when-to-use/when-not guidance and no mention of the sibling run_lu_companies, so routing must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the RESA publications of one Luxembourg company (LBR / RCS), newest first: publication number, date, type, details and consult mode. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | RCS number or registry URL. e.g. B82454 | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses ordering ('newest first') and the billing trait ('1 point per returned record'), which is real behavioral context beyond the schema, but omits auth requirements, rate limits, and failure behavior for a company that has no filings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence plus a short cost clause. The resource and identifier scope are front-loaded, and every phrase (ordering, returned fields, point cost) earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description compensates by enumerating the returned fields (publication number, date, type, details, consult mode). It falls slightly short on pagination semantics despite max_items/start_page existing, but is otherwise complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented and the baseline is 3. The description lightly reinforces that 'company' accepts an LBR/RCS identifier but adds no syntax or format detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and resource ('RESA publications of one Luxembourg company'), plus the identifier scheme (LBR / RCS) and even the returned fields. An agent can tell this apart from run_lu_companies / run_lu_companies_search, which enumerate companies rather than filings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description never says when to reach for this over the sibling country-filings tools or the Luxembourg company-search tools. 'Of one Luxembourg company' implies a prerequisite (you already need a company identifier), but there are no explicit conditions, exclusions, or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Latvia registry (Register of Enterprises) by registration number or registry URL: name, status, registration date, address, legal form, capital, officers, shareholders and beneficial owners. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Registration number or registry URL. e.g. 40003000642 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does add real value by disclosing the cost model ('Flat 5 points per successful run') and enumerating the returned data fields in the absence of an output schema, but it says nothing about failure behavior, auth requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the verb, resource, and country registry before the field list; the cost sentence is a separate, useful clause. The middle field enumeration is long but earns its place given there is no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-record lookup with one required identifier and no output schema, the description supplies the missing return-value information by naming the fields returned, plus pricing. It is nearly complete, with only error/auth behavior left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter, so the schema already documents the accepted formats and gives an example. The description's 'registration number or registry URL' largely restates the schema and adds no syntax or format detail beyond it, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (Get) plus a precisely scoped resource: one Latvia registry company, identified by registration number or registry URL. The singular 'one company' combined with an identifier input clearly separates it from the sibling run_lv_companies_search, which takes query terms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the phrase 'by registration number or registry URL', which tells the agent what input shape is expected, but there is no explicit when-to-use/when-not guidance and no mention of run_lv_companies_search or run_lv_company_filings as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Latvia company registry (Register of Enterprises) by company name or registration number: name, registration number, status, address and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Company name. e.g. latvijas gāze | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the output fields and the cost model ('1 point per returned record'), which is real value beyond the schema, but it omits pagination semantics (despite start_page/max_items), any auth or rate-limit notes, and whether status filtering is exact. Adequate but incomplete for a zero-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence covering source, query modes, and return fields, followed by a short cost note. Every clause earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description does the right work by enumerating returned fields and stating the per-record cost. The main residual gap is pagination behavior for a 250-cap result set, but overall it is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, and the description earns extra credit by clarifying that the keyword accepts a registration number in addition to a company name — the schema description for keyword only mentions 'Company name'. That resolves a genuine ambiguity the schema leaves open.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (Latvia company registry / Register of Enterprises) and adds the query surface (company name or registration number) plus returned fields. It is clear and self-contained, but it does not explicitly differentiate itself from the near-identical sibling run_lv_companies (the non-search/get variant) or run_lv_company_filings, which sit directly adjacent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use, when-not-to-use, or alternative guidance. The phrase 'by company name or registration number' hints at query modes but says nothing about choosing this over run_lv_companies or run_lv_company_filings. An agent must infer usage entirely from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the filed annual reports of a Latvia company (Register of Enterprises) by registration number or registry URL, newest first: financial year, type and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Registration number or registry URL. e.g. 40003000642 | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. It does add real value beyond the schema by disclosing result ordering ('newest first'), the returned fields, and a cost model ('1 point per returned record'), which is genuine behavioral context. However, it omits pagination behavior (start_page/max_items interplay), auth/permission needs, and failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence plus a short cost note, with the resource and scope front-loaded and no filler. It is efficient, though the payoff sentence is appended rather than integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully names what each record contains (financial year, type, link), and the cost note sets expectations. Pagination semantics for start_page/max_items are only covered by the schema, which is a minor gap for a list tool that can return up to 250 records.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 three parameters. The description only restates the 'company' input formats (registration number or registry URL) that the schema itself already gives, adding no meaning for max_items or start_page. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the filed annual reports of a Latvia company') with the source register named, and describes the returned fields (financial year, type, link), which clearly separates it from the sibling run_lv_companies / run_lv_companies_search profile tools. It does not explicitly name an alternative sibling, so it stops just short of the top band.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: this is the tool you call when you want a Latvian company's annual filings given a registration number or registry URL. There is no explicit when-to-use vs when-not guidance and no routing to run_lv_companies or run_lv_companies_search for profile data, leaving the comparison to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Mercari (Japan) item by id or URL: title, description, price in JPY, status (on sale / sold out), photos, brand, category path, condition, shipping payer/method/origin/days, likes, comments, seller (name, reviews, star rating, verified) and item features. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| item | Yes | Item ID or URL. e.g. m47341865350 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does disclose two useful behavioral facts: the operation is a pure read of a single item, and it costs a flat 5 points per successful run, which lets the agent reason about budget. It stops short of covering failure behavior, URL-format tolerance, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action and key input, followed by the payload inventory. The field enumeration is long but each item earns its place because no output schema exists. No filler or marketing language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the exhaustive return-field inventory (price/currency, status, shipping details, seller info) is exactly the right compensation and tells the agent what it will get. Combined with the cost disclosure, the definition is nearly complete for a single-parameter lookup, with only error/edge-case behavior missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'item' parameter already documents that it accepts an ID or URL with an example. The description's 'by id or URL' simply restates the schema, adding no format detail, so the baseline 3 for high-coverage schemas applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get a Mercari (Japan) item by id or URL'), and the 'by id or URL' qualifier implicitly separates it from the sibling run_mercari_items_search. It is clear and unambiguous, but it never names the search sibling explicitly, so differentiation is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the agent can infer it should call this when it already holds an item ID or URL rather than a query string. There is no explicit when-to-use statement, no exclusion of the search path, and no note about what happens with a malformed or non-existent ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Mercari (Japan) items by keyword with category, sort, status and price filters. Returns items with id, URL, name, price (JPY), status, thumbnail and photo. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: score = Relevance, created_time = Newest, price = Price, num_likes = Most liked | |
| order | No | Order. Options: desc = Descending, asc = Ascending | |
| status | No | Status | |
| keyword | Yes | Search term. e.g. iphone 15 | |
| max_items | No | Max items (up to 500) | |
| price_max | No | Max price (JPY) | |
| price_min | No | Min price (JPY) | |
| start_page | No | Starting page | |
| category_id | No | Category ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the return fields and a per-record point cost, but omits other behavioral traits such as read-only nature, pagination behavior, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences: the first front-loads purpose and filters, the second covers return fields and cost. Every clause earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description appropriately lists the returned fields and the point cost. It is mostly complete for a search tool, though it does not explain pagination or the interaction between start_page and max_items.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 every parameter with descriptions and enums. The description mentions category, sort, status, and price filters but adds no syntax, defaults, or format details beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Search') and resource ('Mercari (Japan) items') with the filtering dimensions, distinguishing it from other marketplace search tools by country. It does not explicitly contrast with the sibling run_mercari_items, which may retrieve a single item, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not state when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it. It only names filters, leaving the agent to infer usage context from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company notice from the Mexican Registro Público de Comercio publications (PSM) by publication number: company name, legal form, publication type, title and date, a link to the published text and the publication history. 5 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Publication number. e.g. 2026-0000001606 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It helpfully discloses the return payload (company name, legal form, type, title, date, link, publication history) and a cost signal ('5 point per returned record'), but says nothing about auth requirements, behavior on an invalid publication number, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence that front-loads the action, source, and key, followed by a short cost note. Every clause earns its place, though the field enumeration makes it long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-record lookup with one fully-documented parameter and no output schema, the description covers what comes back. It omits how an agent should obtain a valid publication number and any failure behavior, which leaves a real gap in the workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents the 'company' parameter as a publication number with an example. The description's 'by publication number' corroborates and clarifies the misleadingly-named parameter, but adds no syntax or format detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get one company notice), the exact source (Mexican Registro Público de Comercio / PSM publications), the lookup key (publication number), and the returned fields. It is clearly distinguishable from run_mx_companies_search, though it never names its siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by publication number' implies the prerequisite (you must already have a publication number), but there is no explicit when-to-use guidance, no routing to run_mx_companies_search or run_mx_company_publications to obtain that number, and no stated exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Mexican companies by name in the company publications of the Registro Público de Comercio (PSM): name, legal form and the latest publication with its number, type, title and date. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Company name. e.g. cemex | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose a useful cost model ('1 point per returned record') and describes the shape of returned data, but says nothing about authentication, rate limits, or pagination behavior despite start_page/max_items existing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the core action (search by name) before the source and return fields. No filler, though the return-field enumeration is slightly list-heavy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description usefully enumerates the return fields and discloses the per-record cost. For a 4-parameter search tool with full schema coverage, this is largely complete, with only paging/auth behavior left unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 keyword, status, max_items and start_page. The description only reinforces the 'by name' search intent and adds no extra syntax or format detail; baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specifies a clear verb (Search) and resource (Mexican companies) and names the precise data source, the Registro Público de Comercio company publications. It also enumerates the returned fields (name, legal form, latest publication with number/type/title/date), so an agent knows exactly which sibling this is versus run_mx_companies or run_mx_company_publications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by name' implies the usage context, but there is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives such as run_mx_companies or run_mx_company_publications. Usage is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All published notices of one company in the Mexican Registro Público de Comercio publications (PSM): assemblies, balances, capital and structure changes, with date, type, title and a link to the published text. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Company name or publication number. e.g. Cemex, S.A.B. de C.V. | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It helpfully discloses the returned fields (date, type, title, link) and the cost model (1 point per returned record), but it does not explain pagination, the result cap implied by max_items, or whether 'All published notices' truly means exhaustive coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler and is front-loaded with the resource and scope. The first sentence is dense and could be slightly easier to scan, but overall it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only retrieval tool with no output schema, the description provides useful return-field context and billing behavior. It is not fully complete because pagination behavior and guidance on choosing this tool over related company tools are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 company, max_items, and start_page. The description adds no parameter-specific meaning beyond what the schema provides, making the baseline score appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource — published notices from the Mexican Registro Público de Comercio (PSM) for one company — and lists the covered notice types. It is specific enough to distinguish this from general company lookup tools, but it does not explicitly name or differentiate itself from the related MX company/search siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus run_mx_companies, run_mx_companies_search, or other filing/publication tools. The use case is implied by the description, but no alternatives, prerequisites, or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Products in a Newegg category by category id or category page URL: price, rating, seller and stock, with sort. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: 1 = Lowest price, 2 = Highest price, 3 = Best selling, 4 = Best rating, 5 = Most reviews | |
| category | Yes | Category. e.g. 100011693 | |
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose a cost model ('1 point per returned record') and the fields each record yields, which is genuine added context, but it says nothing about pagination behavior, rate limits, or what happens with large max_items values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence covering scope, inputs, outputs and cost; no filler. It is terse to the point of omitting pagination/output detail, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter listing tool with no annotations and no output schema, the description conveys what a record contains and the cost per record, which is decent. However, it leaves pagination semantics (start_page, max_items) and the absence of a return schema unexplained, so an agent still has gaps to close.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds one useful nuance beyond the schema: the category parameter accepts a category page URL as well as an id. The sort semantics are already fully documented in the schema's enum description, so no further credit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: products within a Newegg category, retrieved by category id or page URL, with fields enumerated (price, rating, seller, stock). It is distinguishable from generic siblings like run_newegg_products or run_newegg_products_search, though it never names them to sharpen the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance, no prerequisites, and no pointer to alternatives such as run_newegg_products_search or run_newegg_sellers_products. Usage is only weakly implied by 'in a Newegg category'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Newegg product by item number or URL: price, rating, specifications, images, offers price range and seller. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Item number or URL. e.g. N82E16820147903 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It helpfully discloses the return payload fields and the cost model ('Flat 5 points per successful run'), but says nothing about error behavior for invalid item numbers, rate limits, or auth requirements. Meaningful but incomplete disclosure for a zero-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both earning their place: the first front-loads the action, scope and return fields, and the second discloses the per-call cost. Tight and well ordered with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-param read tool with no output schema, the description usefully enumerates the returned fields, compensating for the missing output schema. It omits error/edge-case behavior, which keeps it short of full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single 'product' parameter is already documented as 'Item number or URL. e.g. N82E16820147903'. The description repeats the same dual-format hint but adds no additional syntax or format detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — 'Get one Newegg product by item number or URL' — and enumerates the returned data (price, rating, specifications, images, offers price range, seller). This clearly separates it from sibling list/search tools like run_newegg_products_search and run_newegg_categories_products, though it never names them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'one Newegg product ... by item number or URL' signals a single-item lookup, distinguishing it implicitly from the search and category siblings. However, it never states when to prefer this over run_newegg_products_search, nor any prerequisite such as needing a valid item number.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every marketplace buying option for a Newegg product: seller, price, shipping, condition and ships-from. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Item number or URL. e.g. N82E16820147903 | |
| max_items | No | Max items (up to 500) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden alone. It usefully discloses the billing model ('1 point per returned record') and the shape of each record, but says nothing about pagination, authentication needs, or whether results can be empty/multiple per seller.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences; the capability and returned fields are front-loaded and the cost note is a clean trailing clause. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by listing the returned fields and the credit cost, which is enough for correct invocation. It stops short of addressing pagination or result-count expectations for a tool capped at 500 items.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (product, max_items) are already documented with type, bounds, and an example. The description adds no syntax or format detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb+resource ('every marketplace buying option for a Newegg product') and enumerates the returned fields (seller, price, shipping, condition, ships-from). An agent can distinguish this from run_newegg_products or run_newegg_sellers_products, though the description never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as run_newegg_products_search. The agent must infer that this is the offers-listing endpoint for a known product.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Owner reviews for a Newegg product: rating, title, text, pros, cons, author, date and helpful votes. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Item number or URL. e.g. N82E16820147903 | |
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully lists the returned fields and states a cost of '1 point per returned record', which is real behavioral context, but it omits whether the operation is read-only, how pagination works beyond the schema, and any rate limits or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with purpose and return fields, followed by a useful cost note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter read tool with no output schema and no annotations, the description covers what the tool does and what it returns. It is slightly incomplete on usage guidance and explicit read-only behavior, but overall sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 product, max_items, and start_page adequately. The description adds no parameter-specific meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the resource precisely: owner reviews for a Newegg product, plus the data fields returned. Clearly distinguishable from product-detail siblings like run_newegg_products, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites, and no alternative tools mentioned. The agent must infer from the name alone that this tool is for Newegg product reviews rather than, say, run_ebay_product_reviews or run_newegg_products_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Newegg products by keyword with sort: price, rating, seller and stock. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: 1 = Lowest price, 2 = Highest price, 3 = Best selling, 4 = Best rating, 5 = Most reviews | |
| keyword | Yes | Search term. e.g. logitech g502 | |
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose a meaningful cost trait ('1 point per returned record'), but omits read-only nature, pagination behavior, and any auth/rate-limit context. The cost signal is genuine added value, but the disclosure is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with the core action front-loaded and the pricing note appended. Little waste, though the trailing sort phrase is both inaccurate and the weakest part of the sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward search tool with full schema coverage and no output schema, the description is adequate on purpose but thin on routing and behavioral context. The cost note helps, but usage guidance and sibling differentiation are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline would be 3. However, the description's sort framing ('price, rating, seller and stock') does not match the actual enum (lowest/highest price, best selling, best rating, most reviews) – 'seller and stock' are not sort options, so it risks misleading rather than clarifying.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (Newegg products) with the primary constraint (by keyword). It distinguishes by marketplace but does not differentiate itself from the sibling run_newegg_products (the non-search variant) or the many other marketplace search tools, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance, and no alternatives are named despite a crowded neighborhood of Newegg siblings (run_newegg_products, run_newegg_categories_products, run_newegg_products_reviews). The agent gets no routing help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Newegg marketplace seller store by store key or URL: rating, followers, badges, legal name and location. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| seller | Yes | Seller store key or URL. e.g. BioStar |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It usefully discloses a cost trait ('Flat 5 points per successful run') and lists returned fields, implying a read-only operation, but it omits authentication requirements, rate limits, error behavior, and pagination or reliability details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first front-loads the action, resource, input form, and returned fields; the second adds the cost trait. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with no output schema and no annotations, the description covers purpose, accepted input, returned attributes, and cost. It is nearly self-sufficient, with only auth and rate-limit context missing to reach full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter is already fully documented with an example ('BioStar'). The description repeats 'store key or URL' but adds no new meaning beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Get one Newegg marketplace seller store', and clarifies scope with a list of returned attributes. It differentiates naturally from sibling tools like run_newegg_sellers_products by emphasizing a single seller store rather than products, but it does not explicitly name or contrast with any alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool retrieves and the accepted input form, but gives no when-to-use guidance, no conditions for choosing it over alternatives such as run_search or run_newegg_sellers_products, and no exclusions. Usage must be inferred entirely from the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A Newegg marketplace seller's products by store key or store URL. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| seller | Yes | Seller store key or URL. e.g. BioStar | |
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose the cost model ('1 point per returned record'), which is genuinely useful. However, it says nothing about pagination behavior, return format, or any access requirements, so the safety/behavior profile remains thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler: the resource and its identifier are front-loaded, and the pricing note follows. Nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity list-style retrieval tool with full schema coverage and no output schema, so the description need not explain return values. What it provides (what is returned, how it is identified, and the cost) is sufficient, with only pagination behavior left implicit in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented in the schema, including the seller key/URL and the max_items/start_page bounds. The description repeats the seller input ('store key or store URL') without adding format or syntax detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource (a Newegg marketplace seller's products) and the input that identifies the seller (store key or URL). It is clearly distinguishable from siblings like run_newegg_sellers (seller details) and run_newegg_products (catalog lookup), though it never names an alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance, and no alternative is named despite many overlapping Newegg siblings. The phrase 'by store key or store URL' hints at the accepted input but does not tell an agent when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Netherlands registry (KVK Handelsregister) by KVK number or registry URL: name, status, registration date, address, legal form and establishments. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Registration number or registry URL. e.g. 17001910 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose useful behavior: it lists exactly what data comes back (name, status, registration date, address, legal form, establishments) and states the billing model ('Flat 5 points per successful run'). It does not cover error behavior or whether a bare number vs. URL changes the result, which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both load-bearing: the first front-loads the action, resource, identifier forms, and return fields; the second adds cost. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, no-output-schema tool, the description supplies the missing return-value information by enumerating the fields, plus the pricing note. It is complete enough to call correctly; only the precise response shape and failure modes are left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents the single 'company' parameter with an example ('17001910'). The description restates the accepted forms (KVK number or registry URL) without adding format rules or edge-case handling, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get one company), the exact resource (Netherlands registry / KVK Handelsregister), the identifier forms accepted (KVK number or registry URL), and enumerates the returned fields. The singular 'one company' cleanly separates it from the run_nl_companies_search sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The requirement to supply a registration number or registry URL implies this is a direct-identifier lookup rather than a name search, but the description never names run_nl_companies_search as the alternative or states when each should be chosen. Usage is inferable but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Netherlands company registry (KVK Handelsregister) by company name: name, registration number, status, address and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Company name. e.g. philips | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It valuably discloses the data source, returned fields, and billing cost (1 point per returned record), but it omits explicit read-only status, rate limits, pagination behavior, and error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no wasted text. It covers the registry, search key, returned fields, and cost efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple country-registry search with full schema coverage and no output schema, the description is nearly complete: it names the source, search basis, returned fields, and billing cost. It could be stronger by explicitly distinguishing run_nl_companies and noting pagination or rate-limit behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameter semantics are already well documented. The description mentions searching by company name but adds no additional meaning for status, max_items, or start_page beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: search the Netherlands company registry (KVK Handelsregister) by company name, and lists returned fields. It is clearly distinguishable from generic search tools, but it does not explicitly differentiate itself from the sibling run_nl_companies tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear usage context by specifying Netherlands registry search by company name. It does not state when not to use it or name alternative sibling tools, so it falls short of explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Norway registry (Brønnøysundregistrene, Enhetsregisteret) by organisation number or registry URL: name, status, registration date, address, legal form, industry codes and board/signatory roles, share capital, employees, previous names, auditor, liens and related units. 5 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Organisation number or registry URL. e.g. 923609016 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does add genuinely useful non-schema information — '5 point per returned record' credits the cost of the call, and the field enumeration previews the response shape. However, nothing is said about authentication, rate limits, record-not-found behavior, or whether the lookup is a read-only/safe operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and key are front-loaded in the first clause, then the returned-field list follows. The field inventory is long, but it earns its place because there is no output schema to describe the return shape.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-lookup tool with no output schema, the description compensates by enumerating the returned data and disclosing the per-record cost. The remaining gap is the absence of any error/not-found or access-permission context, which keeps it short of a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter already documents 'Organisation number or registry URL' with an example, so the baseline is 3. The description restates the same accepted formats without adding format rules, validation, or normalization detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one company') and pins the exact source ('Norway registry, Brønnøysundregistrene, Enhetsregisteret'), which cleanly separates it from run_no_companies_search. It also enumerates the returned fields, so the agent knows precisely what this lookup yields without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The lookup key is made explicit — 'by organisation number or registry URL' — which tells the agent this is a single-record retrieval rather than a discovery call. It does not name run_no_companies_search as the path to obtain an org number, so the alternative is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Norway company registry (Brønnøysundregistrene, Enhetsregisteret) by company name: name, organisation number, postal code and place, and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Company name. e.g. equinor | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does add useful cost context ('1 point per returned record'), which tells the agent results are metered, but it omits any auth/permission requirements and does not characterize pagination or result caps beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the verb and target. The enumerations of output fields and cost are compact and earn their place given there is no output schema, though the inline field list makes it slightly denser than strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully enumerates returned fields and discloses cost. It is nearly complete for a simple search tool, missing only pagination behavior (how start_page/max_items interact) and any guidance on result limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both keyword, max_items, and start_page are already documented in the schema. The description's listed items (name, org number, postal code, place, link) are returned fields, not parameters, so it adds no parameter-level meaning. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (Norway company registry, with both Brønnøysundregistrene and Enhetsregisteret named), and scopes it to company-name lookup. This cleanly distinguishes it from siblings like run_no_companies (non-search) and run_no_company_filings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by company name' implies the intended lookup usage, and the required keyword param reinforces it. However, there is no explicit when-to-use-vs-alternative guidance, e.g. when to pick this over run_no_companies or a filings tool, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the registry announcements (Kunngjøringer) of a Norway company (Brønnøysundregistrene) by organisation number or registry URL, newest first: date, announcement type and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Organisation number or registry URL. e.g. 923609016 | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses sort order (newest first), returned fields (date, announcement type, link), and a billing trait (1 point per returned record) that is nowhere in the schema. However, it says nothing about pagination behavior for start_page, the 250-item cap, or error handling for an invalid org number.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that packs scope, input format, ordering, and return fields with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly summarizes the returned record shape and ordering, and its read-only nature is evident from 'List'. It is nearly complete, missing only pagination/limit semantics that the schema partly covers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented. The description restates the company input format but adds no new semantics for company, max_items, or start_page, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and a precise resource (registry announcements / Kunngjøringer of a Norwegian company from Brønnøysundregistrene). This cleanly separates it from the sibling listing tools run_no_companies / run_no_companies_search, though it does not name a sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It indicates the accepted input forms (organisation number or registry URL), which implies the calling context, but gives no explicit when-to-use guidance, no exclusions, and no direction to an alternative sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the New Zealand registry (Companies Register) by registration number or registry URL: name, status, registration date, address and legal form. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Registration number or registry URL. e.g. 1157956 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the return fields (name, status, registration date, address, legal form) and a cost model ('Flat 5 points per successful run'), but says nothing about read-only nature, auth requirements, rate limits, or failure behavior for an invalid identifier.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the resource and identifiers are front-loaded, followed by the return fields and cost. No filler, and every clause adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup with full schema coverage and no output schema, the description is nearly complete: it names the source, accepted identifiers, return fields, and cost. It falls short only on behavioral edges (auth, rate limits, invalid-input handling) that an unannotated mutation-free tool would ideally cover.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the lone 'company' parameter is already documented with format and an example. The description restates the same accepted input types (registration number or registry URL) without adding syntax or validation detail, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one company from the New Zealand registry'), lists the exact fields returned, and the phrase 'one company' implicitly contrasts with the sibling run_nz_companies_search. An agent can tell it apart from the search variant without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear an identifier is required ('by registration number or registry URL'), which implies usage, but it never explicitly states when to use this versus run_nz_companies_search, nor any prerequisites. Usage is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the New Zealand company registry (Companies Register) by company name: name, registration number, status, address and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Company name. e.g. fonterra | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden. It does disclose a meaningful behavioral trait — '1 point per returned record' — which signals a cost/consumption model an agent would not otherwise know. However, it omits pagination behavior (relevant given start_page/max_items) and any auth or rate-limit context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tightly-packed sentence with the resource and return fields front-loaded, plus a short cost clause. Nothing is padded, though the return-field list and cost note read as two loosely joined fragments rather than a structured statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter search tool with full schema coverage and no output schema, the description compensates well by naming the fields returned and the cost model. The main gap is guidance on when to pick this over the detail/documents siblings, and how pagination interacts with the point cost.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (keyword, status enum, max_items cap, start_page) already documented in the schema, so the baseline is 3. 'By company name' merely restates the keyword parameter and adds no format or matching hints (partial vs exact) beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (New Zealand company registry / Companies Register), and enumerates the fields returned (name, registration number, status, address, link). It is distinguishable from the detail sibling run_nz_companies and from run_nz_company_documents, but never explicitly contrasts itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage via 'by company name', but gives no when-to-use guidance and never names the alternative (run_nz_companies for a single known entity, run_nz_company_documents for filings). The agent must infer routing from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Documents filed by one New Zealand company (Companies Register): date, type and file links. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Registration number or registry URL. e.g. 1157956 | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the pricing model ('1 point per returned record') and the return fields, which is real added value, but says nothing about pagination interaction between start_page/max_items, auth needs, or whether the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the resource and scope front-loaded and the cost note appended. No filler, though the parenthetical '(Companies Register)' is slightly redundant with the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter list tool with full schema coverage and no output schema, the description covers what the tool returns and its cost. It could still clarify how to source the company identifier and how paging relates to max_items, but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so company, max_items, and start_page are already documented in the schema. The description adds no syntax or format detail beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (documents filed by one New Zealand company on the Companies Register) with the fields returned (date, type, file links). It is clearly distinct from run_nz_companies / run_nz_companies_search, though it does not name those siblings to make the contrast explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'one New Zealand company' implies you must already have a company identifier, but the description never states that you should obtain it via run_nz_companies first, nor does it name any alternative or exclusion. Usage is inferable but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full category tree of an OLX marketplace: id, name, alias, parent id, depth, child ids, URL and live offer count. 5 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Level | |
| domain | No | Marketplace. Options: olx.pl = olx.pl (Poland), olx.ua = olx.ua (Ukraine), olx.ro = olx.ro (Romania), olx.bg = olx.bg (Bulgaria), olx.pt = olx.pt (Portugal), olx.kz = olx.kz (Kazakhstan), olx.uz = olx.uz (Uzbekistan) | |
| max_items | No | Max items (up to 500) | |
| parent_id | No | Parent category ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds real behavioral value by disclosing the per-record cost ('5 point per returned record') and the exact shape of each returned record, which tells the agent the output is a category tree with offer counts. Still missing: auth requirements, whether counts are live/approximate at call time, and any rate or pagination notes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both front-loaded and earning their place: the first specifies the resource and its return shape, the second discloses cost. No filler or restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description appropriately enumerates the returned fields and adds the cost signal, which is enough for an agent to call and interpret the result. It omits usage context and any note on the max_items=500 cap or tree traversal via parent_id/level, but nothing critical for invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema documents level, domain (with per-marketplace enum labels), max_items, and parent_id, so the baseline is 3. The description adds nothing about parameter behavior — e.g. how level and parent_id interact for scoping the tree — beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource — 'Full category tree of an OLX marketplace' — and enumerates the returned fields (id, name, alias, parent id, depth, child ids, URL, offer count), so the agent knows exactly what it gets. It does not, however, differentiate itself from the nearby sibling run_olx_categories_filters, which an agent could easily confuse with this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this versus run_olx_categories_filters, run_olx_offers, or run_olx_regions. No prerequisites, no conditions for choosing level vs parent_id. Usage must be inferred entirely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Category-specific search filters of an OLX category (keys, types, allowed values and ranges) to use in offers search. 5 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Marketplace. Options: olx.pl = olx.pl (Poland), olx.ua = olx.ua (Ukraine), olx.ro = olx.ro (Romania), olx.bg = olx.bg (Bulgaria), olx.pt = olx.pt (Portugal), olx.kz = olx.kz (Kazakhstan), olx.uz = olx.uz (Uzbekistan) | |
| max_items | No | Max items (up to 500) | |
| category_id | Yes | Category ID. e.g. 2298 (from the categories endpoint) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose a meaningful behavioral trait — the '5 point per returned record' cost — which is not in the schema. However, it omits read-only confirmation, rate limits, or pagination behavior, leaving notable gaps for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the resource and its return content, followed by the cost note. No filler, though the cost sentence could be slightly better integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only lookup tool with full schema coverage and no output schema, the description conveys what is returned (filter keys, types, allowed values, ranges) and the cost per record, which is sufficient for an agent to call it correctly. Minor gaps remain around error/auth behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so category_id, domain, and max_items are fully documented in the schema (including the domain enum and the max_items 500 cap). The description adds no parameter-level syntax or constraints, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: retrieves category-specific search filters (keys, types, allowed values, ranges) for an OLX category. It differentiates from run_olx_categories by clarifying this returns filter metadata, not the category list itself, though it doesn't explicitly name that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'to use in offers search' implies the workflow (fetch filters before calling an offers search tool), but there is no explicit when-to-use or when-not-to-use guidance, nor a named alternative tool. Usage is only inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one OLX ad by id or URL: price, description, location with coordinates, photos, attributes and seller. 5 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| offer | Yes | Offer. e.g. Offer id or URL, e.g. 1101345925 | |
| domain | No | Marketplace. Options: olx.pl = olx.pl (Poland), olx.ua = olx.ua (Ukraine), olx.ro = olx.ro (Romania), olx.bg = olx.bg (Bulgaria), olx.pt = olx.pt (Portugal), olx.kz = olx.kz (Kazakhstan), olx.uz = olx.uz (Uzbekistan) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses a pricing trait ('5 point per returned record'), which is real value an agent cannot get from structured fields, but it omits auth requirements, rate limits, and failure behavior for an invalid id or URL.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence front-loads the operation and its scope, then lists the return payload and the cost. Nothing is padded or repeated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter lookup with no output schema, the description usefully enumerates the returned fields and the credit cost. The only notable gap is that the optional 'domain' marketplace selector is never mentioned in prose, leaving marketplace disambiguation entirely to the schema enum.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both the 'offer' id/URL semantics and the domain enum are already fully documented in the schema. The description restates the id-or-URL acceptance but adds no syntax or formatting detail beyond it, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one OLX ad by id or URL') and enumerates the returned payload (price, description, location with coordinates, photos, attributes, seller). The word 'one' plus the id/URL input distinguishes it from the sibling run_olx_offers_search without needing to open either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The singular lookup framing implies the usage context and implicitly contrasts with run_olx_offers_search, but the description never explicitly names the alternative or states when to prefer this single-record fetch. No prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search live OLX ads by keyword with category, price, condition, seller type, location, delivery and sort. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: relevance = Relevance, newest = Newest, oldest = Oldest, price_asc = Price: low to high, price_desc = Price: high to low | |
| domain | No | Marketplace. Options: olx.pl = olx.pl (Poland), olx.ua = olx.ua (Ukraine), olx.ro = olx.ro (Romania), olx.bg = olx.bg (Bulgaria), olx.pt = olx.pt (Portugal), olx.kz = olx.kz (Kazakhstan), olx.uz = olx.uz (Uzbekistan) | |
| city_id | No | City ID | |
| keyword | No | Search term. e.g. iphone | |
| user_id | No | Seller user ID | |
| distance | No | Distance (km around the city) | |
| condition | No | Condition. Options: new = New, almost-new = Almost new, used = Used, refurbished = Refurbished, outlet = Outlet, damaged = Damaged, others = Others | |
| max_items | No | Max items (up to 500) | |
| max_price | No | Max price (marketplace currency) | |
| min_price | No | Min price (marketplace currency) | |
| region_id | No | Region ID | |
| owner_type | No | Seller type. Options: private = Private sellers, business = Business sellers | |
| start_page | No | Starting page (50 offers per page, up to 20) | |
| category_id | No | Category ID | |
| district_id | No | District ID | |
| has_delivery | No | OLX delivery only |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does add one genuinely useful behavioral fact the schema does not carry: billing at 1 point per returned record. However it says nothing about pagination limits behavior, auth/marketplace requirements, or what the response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short clauses, front-loaded with the verb and resource, then the billing note. Nothing is redundant. It is not a 5 because the facet enumeration is somewhat boilerplate list-building rather than prioritizing what an agent most needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 16-parameter tool with no annotations and no output schema, the description is thin. It does not explain that all parameters are optional, how IDs like city_id/category_id are sourced (run_olx_categories, run_olx_regions), or pagination behavior, leaving real gaps for an agent to fill.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented with enums and ranges, which sets the baseline at 3. The description's facet list (category, price, condition, seller type, location, delivery, sort) mirrors parameters without adding syntax, formats, or cross-parameter constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb+resource ('Search live OLX ads') plus the facet dimensions it covers (category, price, condition, seller type, location, delivery, sort). This is more than a restatement of the name. It falls short of a 5 only because it doesn't differentiate from the closely named sibling run_olx_offers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'Search ... by keyword' and the cost note ('1 point per returned record') hints at a metered operation, but there is no explicit when/when-not guidance and no routing to alternatives such as run_olx_offers, run_olx_users_offers, or the category/region lookup tools an agent would need to obtain IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
OLX geography: top-level regions or the cities of one region, with ids and coordinates for offers search. 5 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Marketplace. Options: olx.pl = olx.pl (Poland), olx.ua = olx.ua (Ukraine), olx.ro = olx.ro (Romania), olx.bg = olx.bg (Bulgaria), olx.pt = olx.pt (Portugal), olx.kz = olx.kz (Kazakhstan), olx.uz = olx.uz (Uzbekistan) | |
| max_items | No | Max items (up to 500) | |
| region_id | No | Region ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does add a genuinely useful non-schema detail — the '5 point per returned record' credit cost — but says nothing about rate limits, auth, pagination, or what happens with max_items. For a low-risk read lookup this is adequate but thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, purpose front-loaded, no padding. The trailing cost note is terse and slightly awkward ('5 point per returned record') but earns its place as pricing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter read tool with 100% schema coverage and no output schema, the description covers purpose, the region/cities branching, and cost. Remaining gaps (coordinate format, pagination interaction with max_items) are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning the schema lacks: passing region_id switches the call from returning top-level regions to returning the cities of that single region. That mode distinction is not derivable from the parameter list alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (OLX geography) and what it returns (top-level regions, or the cities of one region, with ids and coordinates), and ties it to the offers-search workflow. It is distinguishable from run_olx_categories and run_olx_offers, though it never names a sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the phrase 'for offers search' and by the region-or-cities branching, but there is no explicit when-to-use statement, no conditions, and no named alternative. An agent can infer intent but gets no routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an OLX seller profile by id, uuid or profile URL: account type, registration, last seen, response time and business details. 5 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| user | Yes | User. e.g. User id, uuid or profile URL, e.g. 888517085 | |
| domain | No | Marketplace. Options: olx.pl = olx.pl (Poland), olx.ua = olx.ua (Ukraine), olx.ro = olx.ro (Romania), olx.bg = olx.bg (Bulgaria), olx.pt = olx.pt (Portugal), olx.kz = olx.kz (Kazakhstan), olx.uz = olx.uz (Uzbekistan) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden; 'Get' implies a read, and the 5-points-per-record disclosure is genuinely useful cost context. However, it omits auth/permission needs, rate limits, and failure behavior (e.g. what happens with an invalid or ambiguous identifier), which a no-annotation mutation/read tool should ideally cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the resource and identifier forms, with the cost note in a compact trailing clause. No filler or restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description compensates well by enumerating the profile fields returned, and the cost disclosure covers billing expectations. It is slightly short of complete because the domain parameter's role is never addressed and error/edge-case behavior is unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 both 'user' and 'domain', making 3 the baseline. The description restates the identifier forms from the schema but adds no new meaning, and it never mentions the domain parameter or how it interacts with a bare numeric id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get an OLX seller profile') and enumerates the returned fields (account type, registration, last seen, response time, business details), so the agent knows exactly what it retrieves. It does not name or contrast any sibling such as run_olx_users_offers or run_olx_offers, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the accepted identifier forms (id, uuid, profile URL) suggest it is a profile-lookup step, and the cost line hints at budget sensitivity. There is no statement of when to prefer this over run_olx_users_offers or run_olx_offers, and no prerequisites (e.g. whether domain must match the identifier) are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A seller's active OLX offers by user id, uuid or profile URL, with category filter and sort. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: relevance = Relevance, newest = Newest, oldest = Oldest, price_asc = Price: low to high, price_desc = Price: high to low | |
| user | Yes | User. e.g. User id, uuid or profile URL, e.g. 888517085 | |
| domain | No | Marketplace. Options: olx.pl = olx.pl (Poland), olx.ua = olx.ua (Ukraine), olx.ro = olx.ro (Romania), olx.bg = olx.bg (Bulgaria), olx.pt = olx.pt (Portugal), olx.kz = olx.kz (Kazakhstan), olx.uz = olx.uz (Uzbekistan) | |
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page (50 offers per page, up to 20) | |
| category_id | No | Category ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that only 'active' offers are returned and that cost is '1 point per returned record', which is genuine behavioral context. However, it omits pagination behavior, auth/credential requirements, and rate limits, leaving meaningful gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with the resource and key filters front-loaded, followed by the cost note. Very little waste, though the telegraphic fragment style trades a little clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool spanning 7 marketplaces with no annotations and no output schema, the description is thin. It covers purpose and cost but says nothing about the return shape, page size limits, or which domain the seller must belong to, so an agent still lacks some context needed to call it well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter (sort, user, domain, max_items, start_page, category_id) is already documented in the schema. The description only echoes the user identifier forms and mentions category filter and sort without adding syntax or format detail. Baseline 3 applies when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear resource (a seller's active OLX offers) and how to target it (user id, uuid or profile URL), plus the supported category filter and sort. It implicitly distinguishes itself from the general run_olx_offers and run_olx_offers_search by scoping to a seller's offers, though it never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance and no reference to the alternatives run_olx_offers, run_olx_offers_search, or run_olx_users. The user must infer the appropriate context purely from the resource named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from Owler by slug or URL: description, founded year, headquarters, CEO, revenue and employee estimates, full funding rounds with investors, acquisitions, investments, competitors and latest news. Flat 10 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Company slug or Owler URL. e.g. stripe |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It does disclose one real behavioral trait — a flat 10-point cost per successful run — and enumerates the return payload. But it says nothing about auth requirements, rate limits, or failure behavior when a slug is not found, so it is only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action and location of data, followed by a cost note. The field enumeration is long but earns its place by telling the agent exactly what the payload contains in the absence of an output schema. Slightly dense but no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup with no output schema and no annotations, the description compensates well by listing the returned fields and the point cost. The main gap is the absence of any routing guidance to the search or sub-resource siblings in a very crowded family.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'company' parameter has 100% schema description coverage, including the 'stripe' example, so the schema does the heavy lifting. The description's 'by slug or URL' phrasing mirrors the schema and adds no format detail beyond it. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — fetch one Owler company by slug or URL — and enumerates the returned data (funding rounds, acquisitions, competitors, news). This distinguishes it from the sibling search tool (run_owler_companies_search) and the sub-resource tools (run_owler_companies_competitors, run_owler_companies_news) that each return a subset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'One company ... by slug or URL' implies this is a single-lookup tool rather than a discovery tool, which is useful context. However, it never explicitly names run_owler_companies_search as the way to resolve a company name to a slug, nor does it state any preconditions. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Competitors of one Owler company (slug or URL): name, link, CEO, revenue, employees, funding, headquarters and sector. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Company slug or Owler URL. e.g. uber | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page (10 per page) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral load. It usefully discloses the output fields and the billing model ('1 point per returned record'), but it omits pagination behavior, authentication needs, rate limits, and any safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one front-loaded sentence that identifies the resource, the input, the returned fields, and the cost model. Every clause earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description helpfully lists the fields returned and notes the point cost. It does not explain pagination interplay between max_items and start_page, but the schema covers those parameters fully, so the definition is nearly complete for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameter semantics are already documented in the schema. The description repeats the company input format (slug or URL) but adds no new meaning for max_items or start_page; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (competitors of one Owler company) and the input type (slug or URL), making the tool's purpose unmistakable. It enumerates the returned fields, which further clarifies what the tool does and distinguishes it from general company lookup siblings like run_owler_companies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only states what the tool returns; it gives no explicit when-to-use guidance, no preconditions, and no mention of alternative tools. Without any routing information, an agent must infer usage solely from the name and resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest news about one Owler company (slug or URL): title, summary, publisher, date and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Company slug or Owler URL. e.g. stripe | |
| max_items | No | Max items (up to 10) | |
| news_type | No | News type. Options: all = All (latest 10), news = News (latest 3), blog = Blog (latest 3), videos = Videos (latest 3), press = Press releases (latest 3) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the return fields and a genuinely useful cost model ('1 point per returned record'), which helps the agent reason about max_items. However, it says nothing about authentication, rate limits, or whether results can be paginated beyond the schema's cap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the core purpose front-loaded and the return shape plus cost trailing. No filler and every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description compensates by listing the returned fields (title, summary, publisher, date, link) and the cost. For a low-complexity list tool with fully documented parameters, this is nearly sufficient; only usage context and any pagination behavior are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all three parameters are already documented, including the slug/URL format and the enum values for news_type. The description adds the per-record cost signal but no syntax or format detail beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb+resource combination ('Latest news about one Owler company') and enumerates the returned fields. It is clearly distinct from siblings like run_owler_companies and run_owler_companies_competitors, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when/when-not guidance and no named alternatives. The phrase 'one Owler company' implies single-company scope, but the agent is left to infer when this news tool is preferable to the sibling company or competitor tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Owler companies by name (the site's own suggestion list): company id, name, logo and profile link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Company name. e.g. uber | |
| max_items | No | Max items (up to 250) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does add genuinely useful behavior beyond the schema: the cost model ('1 point per returned record') and the fact that results come from the site's own suggestion list rather than a full-text index. However, it says nothing about pagination beyond max_items, empty-result behavior, or auth requirements, leaving real gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences, front-loaded with the verb and resource, then the return fields and cost. Every clause earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully enumerates the returned fields (id, name, logo, profile link) and the billing rule, which is what an agent needs to plan a call. For a two-parameter, read-only search this is largely sufficient; only the lack of differentiation from run_owler_companies and of pagination semantics keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'keyword' and 'max_items' documented inline (including the 250 cap and an example), so the baseline is 3. The description adds no parameter meaning beyond the schema and does not explain how the suggestion-list behavior interacts with the keyword input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search Owler companies by name') and even names the underlying mechanism ('the site's own suggestion list'), which separates it from the sibling run_owler_companies profile lookup. It lists the returned fields, so the agent knows this is a name-to-id resolver. It stops short of explicitly naming the sibling it differs from, so it lands at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: by advertising 'company id' as a return field, the description hints this is the lookup step before calling run_owler_companies. There is no explicit when-to-use statement and no mention of alternatives among the many company-search siblings (run_owler_companies, run_owler_companies_competitors, run_owler_companies_news).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one entity from the Panama Registro Público (Consulta de Folios Suspendidos) by folio or registry link: name, status, register type, incorporation date and status date. Covers suspended, dissolved, merged and closed entities. 5 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Folio or registry URL. e.g. 1070 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses non-schema behavior: the exact sub-registry consulted ('Consulta de Folios Suspendidos') and a concrete cost of '5 point per returned record', both of which an agent cannot infer 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the verb and resource, followed by scope and cost. No wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by listing the returned fields (name, status, register type, incorporation date, status date). Combined with the cost and coverage info, it is nearly complete for a single-parameter lookup, though failure/empty-result behavior is unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already documents the single 'company' parameter ('Folio or registry URL. e.g. 1070'). The description's 'by folio or registry link' restates that without adding format or syntax detail, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Get one entity from the Panama Registro Público... by folio or registry link', and enumerates returned fields. 'One entity' implicitly distinguishes it from the run_pa_companies_search sibling, though that tool is never named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied (you must already have a folio or registry link), and the covered entity statuses are stated, but there is no explicit when-to-use guidance or comparison to run_pa_companies_search for discovery-style lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Panama Registro Público (Consulta de Folios Suspendidos) by company name or folio number: name, folio, status, register type, incorporation date and status date. Covers suspended, dissolved, merged and closed entities. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Company name or folio. e.g. copa | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the returned fields, that suspended/dissolved/merged/closed entities are covered, and a cost model ('1 point per returned record'). It omits auth requirements, rate limits, and pagination behavior, leaving meaningful gaps for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the action and registry, then the coverage and cost. Every clause carries information; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema, the description tells the agent what fields come back and what entity states are included, and even the credit cost. Missing only paging semantics and usage alternates, which are minor given the complete input schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 keyword, status enum, max_items and start_page. The description only maps the keyword to 'company name or folio number', adding little beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Search') and resource (Panama Registro Público / Consulta de Folios Suspendidos), and enumerates the returned fields plus entity coverage. It does not explicitly differentiate itself from the run_pa_companies sibling, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by company name or folio number' implies how to use the keyword input and mentions which entity states are covered, but there is no explicit when-to-use vs. when-not, and no mention of the run_pa_companies alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enriches a known phone number with profile data when available.
| Name | Required | Description | Default |
|---|---|---|---|
| phone | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The phrase 'when available' hints that results may be partial or empty, which is useful, but it says nothing about what profile fields are returned, credential/rate-limit requirements, or cost.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no filler. It is efficient, though its brevity reflects under-specification rather than disciplined concision.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an enrichment tool with no annotations, no output schema, and 0% parameter coverage, the description omits input format, output shape, and selection versus the US sibling. An agent cannot invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single phone parameter, so the description must compensate and it largely does not. 'A known phone number' implies the number must exist, but no format (e.g. E.164, country code) is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (enriches) and resource (phone number) with what it produces (profile data). However, it does not distinguish itself from the sibling run_phone_enrichment_us, leaving the agent unable to tell which phone-enrichment tool to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites, and no mention of the alternative run_phone_enrichment_us. The agent is left to infer when this general tool applies versus the US-specific sibling or the email-enrichment tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates and enriches a US phone number with carrier and activity details.
| Name | Required | Description | Default |
|---|---|---|---|
| phone | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It states that validation and enrichment occur and lists output categories, but says nothing about authentication, rate limits, idempotency, error handling, or whether the operation is read-only or paid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no wasted words. It states the operation, scope, and output summary immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter enrichment tool with no annotations and no output schema, the description is adequate but incomplete. It gives the purpose and hints at returned fields, but omits parameter formatting, error behavior, and how it relates to the generic run_phone_enrichment sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions, so the description must compensate. It adds that the phone number should be US-based, which is useful, but it does not specify expected format (e.g., E.164, digits only, country code prefix) or validation constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb combination ('Validates and enriches') and a precise resource ('a US phone number'), with additional detail about output ('carrier and activity details'). It distinguishes itself by region from the sibling run_phone_enrichment, but does not explicitly state that it is the US-specific alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this tool when you have a US phone number to validate or enrich. However, no explicit when-to-use guidance, prerequisites, or alternatives are provided, and the sibling run_phone_enrichment is not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the public profile preview of a company by PitchBook id or URL: description, website, founded year, status, employees, industries, parent company, address, social links, FAQs, the latest deals, competitors, investors, investments, affiliates and patent tables shown in the free preview, verticals, related research and news. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Profile id or PitchBook URL. e.g. 439834-78 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose genuinely useful behavior: the result is a limited 'free preview' and the call costs a flat 5 points per successful run. However, it omits auth requirements, rate limits, and error behavior, leaving meaningful gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The verb and resource are front-loaded in the first clause, and the cost note is placed last where it belongs. The long field enumeration is informative but borders on verbose, costing a point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly compensates by enumerating the returned fields, so an agent knows what it gets back. The remaining gap is behavioral (auth, limits, preview truncation), not informational.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'company' param already documents id or URL with an example), so the schema does the heavy lifting. The description merely restates 'by PitchBook id or URL' without adding format or validation detail, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get'), resource ('public profile preview of a company'), and identifier basis ('PitchBook id or URL'). It enumerates the returned fields, making its scope clear and distinguishing it from run_pitchbook_investors, though it never names a sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The requirement of a PitchBook id or URL implies this is for fetching one known company rather than discovering companies (e.g. run_pitchbook_profiles_search), but no when-to-use guidance, prerequisites, or named alternatives are given. Usage is only faintly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the public profile preview of an investor by PitchBook id or URL: description, website, founded year, status, investor types, address, social links, FAQs, counters (investments, portfolio, exits), the latest investments, exits, co-investors and affiliates shown in the free preview, related research and news. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| investor | Yes | Profile id or PitchBook URL. e.g. 509040-73 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it discloses two valuable behavioral traits: the data is limited to what appears in the 'free preview', and each successful run costs a 'flat 5 points'. It does not cover auth needs or failure behavior, but the preview limitation and cost are meaningful non-obvious context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence that opens with the purpose before enumerating return fields; the field list is long but earns its place since there is no output schema. Slight verbosity in enumerating every field, but reasonably efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter lookup with no output schema, the description compensates by enumerating the returned fields, the preview limitation, and the cost. An agent has enough to call it and set expectations, though error/edge handling is unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is already documented with an example id in the schema. The description restates the input ('PitchBook id or URL') but adds no format or semantics beyond what the schema provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get the public profile preview of an investor') plus retrieval key ('by PitchBook id or URL'). This clearly distinguishes it from run_pitchbook_companies (companies) and run_pitchbook_profiles_search (search-based discovery).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'by PitchBook id or URL' phrasing implies this is a direct-lookup tool versus the sibling search tools, so usage context is implied. However, it never explicitly states when to prefer this over run_pitchbook_profiles_search or names any alternative, leaving the routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search PitchBook public profile previews by keyword: name, type (company / investor / fund), profile id and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Profile type. Options: company = Company, investor = Investor, fund = Fund | |
| keyword | Yes | Keyword. e.g. stripe | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It does add genuinely useful context beyond the schema: results are 'public profile previews' (i.e. truncated data, not full profiles) and cost '1 point per returned record', which is a meaningful cost/budget signal. It still omits pagination behavior, authentication requirements, and how previews differ from the dedicated company/investor tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the action and resource, and the cost note is a useful trailing fact. Minor waste in the colon list of return fields, which reads like output documentation in a description slot.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter search tool with no output schema, the description covers the resource, the profile types, and the cost, but leaves pagination semantics (start_page/max_items interplay), result limits, and the relationship to the dedicated PitchBook company/investor tools unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so keyword, type, max_items, and start_page are already documented in the schema; baseline is 3. The description's list of fields ('name, type, profile id and link') actually describes outputs rather than inputs and adds no syntax or format detail for any parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (PitchBook public profile previews) and enumerates the return fields (name, type, profile id and link). It is clear what the tool does, but it never distinguishes itself from nearby siblings such as run_pitchbook_companies, run_pitchbook_investors, or the generic run_search, so the agent must infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use or when-not-to-use guidance and names no alternative. With run_pitchbook_companies and run_pitchbook_investors in the sibling list, the agent gets no signal about which to pick for a given profile type even though this tool's own type enum covers all three.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one product from PitchWall by slug or URL: tagline, full description with pricing and FAQs, website, topics, publish date, social accounts, screenshots and submitter. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product slug or PitchWall URL. e.g. mainbrella-cloud-workspaces-for-ai-agents |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose return content (tagline, description with pricing and FAQs, website, topics, publish date, social accounts, screenshots, submitter) plus a cost model ('Flat 5 points per successful run'). It still omits failure behavior for an invalid or missing product, which is the main remaining gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose before the field inventory and cost. The field list is long, but given there is no output schema each enumerated field does earn its place; still, it is a dense enumeration rather than tight prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter detail tool with no annotations and no output schema, the description supplies exactly the missing pieces: what the call returns and its point cost. Only error/not-found behavior is unaddressed, which is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter exists and schema description coverage is 100%, including a concrete example slug in the schema, so the baseline is 3. The description's 'slug or URL' phrasing merely restates the schema's accepted formats without adding resolution rules or normalization guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource+identifier: 'Get one product from PitchWall by slug or URL'. The 'one product ... by slug or URL' framing cleanly separates it from the sibling run_pitchwall_products_search, which returns lists. An agent can pick between them without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the singular 'one product ... by slug or URL', which suggests a detail lookup that follows a search. However, the description never explicitly names run_pitchwall_products_search as the way to obtain slugs, nor states when this tool should be preferred or what happens if the input is neither a valid slug nor URL.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the newest PitchWall products, or the products of one topic (tag): name, tagline, website, topics, publish date and link. The topic is optional. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Topic (tag). e.g. ai | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the cost model ('1 point per returned record') and the returned fields, but says nothing about pagination behavior despite a start_page parameter, nor about auth or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence front-loads the core action and scope, then lists output fields and cost. Efficient, though the field enumeration slightly blurs the sentence's focus.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description helpfully enumerates the returned fields (name, tagline, website, topics, publish date, link) and the cost, making it callable without further lookup. Pagination semantics remain the only notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 topic, max_items, and start_page with examples and bounds. The description adds only the optionality of topic, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('List ... PitchWall products') with scope (newest, or filtered by topic) and enumerates returned fields. It is clearly distinguishable from run_pitchwall_products in intent, though it never names that sibling to contrast the two.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes 'The topic is optional', which implies the two calling modes (browse newest vs. filter by tag), but gives no explicit when-to-use guidance and never points to run_pitchwall_products as the alternative. Usage is implied rather than directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Poland registry (KRS) by KRS number or registry link: name, status, registration date, address, legal form, NIP/REGON, representatives, capital, shareholders, branches, history. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | KRS number or registry URL. e.g. 0000028860 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It helpfully enumerates the returned data set and discloses a concrete cost rule ('Flat 5 points per successful run'), which is genuinely useful behavioral context, but says nothing about failure behavior for an invalid KRS number, authentication, or whether the call is strictly read-only and idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and identifier forms in one sentence, with the cost note appended. The long field enumeration is dense but substitutes for the missing output schema, so it earns its space; only minor trimming would be possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single required parameter and no output schema, the description compensates by listing the record contents and the points cost, which is what an agent needs to decide whether to call it. Missing only error/edge-case behavior for malformed identifiers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter and schema description coverage is 100%, so the schema already documents 'KRS number or registry URL' with an example. The description restates the same accepted forms without adding format rules, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one company from the Poland registry (KRS)') plus the two accepted identifier forms, which cleanly separates it from the many list/aggregate siblings. It stops short of naming run_pl_companies_search, so the singular-vs-search distinction is only implied by 'one company'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The requirement of a KRS number or registry link implies the caller must already hold an exact identifier, which implicitly steers name-based lookups to run_pl_companies_search, but no alternative is named and no when-not-to-use condition is stated. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Poland company registry (KRS) by company name: name, KRS number, city, register and flags. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Company name. e.g. orlen | |
| max_items | No | Max items (up to 100) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does add genuinely useful non-schema context — the '1 point per returned record' cost signal — but says nothing about authentication, rate limits, or how paging behaves in practice beyond the schema fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence, front-loaded with the registry and lookup key, followed by the return/cost note. Nothing is wasted, though the appended field list is slightly ambiguous about whether those are searchable or returned fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so enumerating the returned fields (name, KRS number, city, register, flags) is a real contribution, and the per-record cost is disclosed. The main remaining gap is pagination/result-size behavior, which is only hinted at by max_items and start_page in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the three parameters are already documented, making 3 the baseline. The description's phrase 'by company name' reinforces the keyword parameter, but the field list (name, KRS number, city, register, flags) reads as returned fields rather than parameter semantics, adding little on that axis.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource — searching the Poland company registry (KRS) by company name — which is clear enough for an agent to act on. It does not, however, distinguish this tool from close siblings such as run_pl_companies or run_pl_company_filings, so the agent must infer the boundary from the name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'Search ... by company name' tells the agent this is the name-keyword lookup entry point, but it never says when to prefer it over run_pl_companies (likely an ID/detail lookup) or run_pl_company_filings. No prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the filed financial documents (annual and consolidated statements, auditor opinions, approval resolutions, management reports) and register entries of a Poland company (KRS) by KRS number or registry link, newest first: date, type, period and entry details. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | KRS number or registry URL. e.g. 0000635012 | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses ordering ('newest first'), the returned fields ('date, type, period and entry details'), and cost ('1 point per returned record'). It omits auth/permission requirements and pagination behavior, which is a modest gap for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and identifier are front-loaded in a single dense sentence, with a short trailing note on cost. The document-type parenthetical is useful specificity rather than padding, though the sentence is long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description supplies the essentials an agent needs: what is returned, the sort order, and the cost. Pagination limits live in the schema, so the remaining gap is small.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both the company identifier format and the max_items/start_page bounds are already documented in the schema. The description's 'by KRS number or registry link' merely restates the schema's 'KRS number or registry URL', and it says nothing about max_items or start_page.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and resource ('filed financial documents ... and register entries of a Poland company (KRS)'), enumerated with concrete document types. It clearly distinguishes this country-specific filings tool from siblings like run_pl_companies and run_pl_companies_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context: it is the tool for filings/register entries of a Polish company, queried by KRS number or registry link. However, it never explicitly contrasts itself with run_pl_companies_search or other country filings tools, nor states when NOT to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Poshmark listing by id or URL: price, brand, size, colors, category, photos, likes/comments, seller and the likers/comments shown on the page. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| item | Yes | Listing. e.g. Listing id or URL, e.g. 6865651dd6c0dc3f3fdfc8ea | |
| domain | No | Domain. Options: poshmark.com = poshmark.com, poshmark.ca = poshmark.ca |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses a useful cost trait ('Flat 5 points per successful run') and implies read-only via 'Get', but omits auth requirements, rate limits, domain default behavior, and error semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences front-load the purpose and append a cost note; the field list is long but earns its place by telling the agent what data comes back. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description compensates by naming returned fields and noting the point cost, while the schema fully covers parameters. It falls short of 5 only because it doesn't state the domain parameter's default or error-handling behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'item' and 'domain' fully documented in the input schema. The description's 'by id or URL' adds no new syntax or constraints beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb 'Get one Poshmark listing' and resource, with 'by id or URL' clearly separating it from search or related-item siblings. It enumerates returned fields (price, brand, size, colors, category, photos, likes/comments, seller, likers/comments shown on the page), so an agent knows exactly what the tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when an id or URL is already known, but gives no explicit when-to-use/when-not guidance and never names alternatives like run_poshmark_items_search or run_poshmark_items_related. An agent must infer that this is for a known single listing rather than discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Comments on a Poshmark listing (author, text, date), by listing id or URL. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| item | Yes | Listing. e.g. Listing id or URL, e.g. 6865651dd6c0dc3f3fdfc8ea | |
| domain | No | Domain. Options: poshmark.com = poshmark.com, poshmark.ca = poshmark.ca | |
| max_items | No | Max comments (up to 500) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the credit cost (1 point per returned record) and names returned comment fields, but omits read-only confirmation, rate/pagination behavior, and whether all comments or a capped set are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short clauses with the resource front-loaded, followed by useful return-field and cost details. Every phrase earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter read tool with no output schema, it names returned fields and the point cost, while the schema fully covers inputs. It leaves only minor gaps around domain default and pagination/cap behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 item, domain, and max_items. The description restates that item accepts a listing id or URL but adds no syntax, domain default, or max_items meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Identifies the resource (comments on a Poshmark listing) and the returned fields (author, text, date), which distinguishes it from siblings like run_poshmark_items_likes. However, the verb is omitted or ambiguous: 'Comments on...' could be read as an action rather than a retrieval, and no sibling alternative is named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives the required identifier form (listing id or URL), but provides no guidance on when to choose this tool over run_poshmark_items, run_poshmark_items_search, or run_poshmark_items_likes. There are no exclusions, prerequisites, or context conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Users who liked a Poshmark listing (handle, name, avatar), by listing id or URL. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| item | Yes | Listing. e.g. Listing id or URL, e.g. 6865651dd6c0dc3f3fdfc8ea | |
| domain | No | Domain. Options: poshmark.com = poshmark.com, poshmark.ca = poshmark.ca | |
| max_items | No | Max likes (up to 500) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, but it does add two useful behavioral facts: the shape of the returned records (handle, name, avatar) and the cost model ('1 point per returned record'). It omits auth requirements, pagination/cursor behavior, and whether max_items truncates silently, which matters for a paid, capped scrape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no padding, and the resource/return shape is front-loaded before the cost note. Could be tighter still, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is the only source of behavior, and it covers just identity-of-resource, return fields, and per-record cost. It leaves out response envelope, pagination, and error/permission conditions, which is thin for a billed endpoint, though the schema handles the inputs fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (item, domain, max_items) are already documented in the schema, including that item accepts an id or URL. The description's 'by listing id or URL' merely restates the schema, adding no new semantics; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and relationship: users who liked a given Poshmark listing, plus the fields returned (handle, name, avatar). The name and description together make it distinguishable from run_poshmark_items_comments or run_poshmark_users_followers without opening a schema, though it never names or contrasts a sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as run_poshmark_users_followers (user-level following) versus this listing-level likes endpoint. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search live Poshmark listings by keyword with department, category, brand, size, color, price, condition, shipping, availability and sort filters. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Sizes (comma separated). e.g. 8, M | |
| sort | No | Sort by. Options: relevance = Relevance, just_in = Just in, price_low_to_high = Price: low to high, price_high_to_low = Price: high to low | |
| brand | No | Brand. e.g. Nike, Coach | |
| color | No | Colors | |
| query | No | Search term (optional). e.g. nike shoes | |
| domain | No | Domain. Options: poshmark.com = poshmark.com, poshmark.ca = poshmark.ca | |
| category | No | Category. e.g. Shoes, Dresses, Bags | |
| shipping | No | Shipping. Options: free = Free shipping, discounted = Discounted shipping | |
| condition | No | Condition. Options: all = All conditions, nwt = New with tags (NWT) | |
| max_items | No | Max items (up to 500) | |
| price_max | No | Max price | |
| price_min | No | Min price | |
| department | No | Department. Options: Women = Women, Men = Men, Kids = Kids, Home = Home, Electronics = Electronics, Pets = Pets, Beauty & Wellness = Beauty & Wellness | |
| start_page | No | Starting page | |
| subcategory | No | Subcategory. e.g. Athletic Shoes, Sneakers | |
| availability | No | Availability. Options: all = All, available = Available, available_and_dropping_soon = Available and dropping soon, dropping_soon = Dropping soon, sold = Sold, not_for_sale = Not for sale |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full disclosure burden. It does provide one genuinely valuable behavioral fact — "1 point per returned record" — which tells the agent this call is metered and that max_items drives cost, but it says nothing about read-only nature, pagination behavior, rate limits, or result freshness beyond the word "live".
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and resource, with the cost note trailing. The long filter enumeration partially duplicates the schema but aids quick scanning; it is not wasteful enough to penalize heavily.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 16-parameter, annotation-free tool with no output schema, the description covers purpose and cost but omits what a result record contains and how start_page interacts with max_items for paging. Adequate but with clear gaps an agent would want filled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with enum values, examples, and min/max bounds for all 16 parameters, so the schema does the heavy lifting and baseline 3 applies. The description only restates the filter categories at a high level without adding syntax or defaults (e.g., default sort, page-size semantics).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Search live Poshmark listings") plus the full filter surface, which is far more precise than the tautological name. It does not explicitly name the sibling run_poshmark_items (single-item lookup) or run_poshmark_items_related, so differentiation is inferable but not spelled out.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase "by keyword" plus the filter list implies the intended case (discovery of listings matching criteria), but there is no explicit when-to-use/when-not statement and no naming of alternatives such as run_poshmark_items for known item IDs. Usage must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Poshmark seller's public closet profile by username or URL: bio, location, followers/following/listing counts, items sold and activity. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| user | Yes | Username or closet URL. e.g. Username or closet URL, e.g. najescloset | |
| domain | No | Domain. Options: poshmark.com = poshmark.com, poshmark.ca = poshmark.ca |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It usefully notes the profile is 'public' (an auth/scope hint) and discloses a flat cost of 5 points per successful run, which is real behavioral value. But it says nothing about failure modes, invalid-username behavior, rate limits, or whether the response is cached, leaving significant gaps for an unannotated read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with the core action and returned fields front-loaded and the pricing note trailing. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by enumerating the profile fields returned (bio, location, follower/following/listing counts, sold, activity), which is what an agent needs to judge relevance. It is complete enough for a 2-parameter, single-resource fetch, though the unannotated behavioral profile remains thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented in the schema. The description's mention of 'by username or URL' loosely mirrors the user param but adds no syntax, format, or domain-selection detail beyond what the schema provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get a Poshmark seller's public closet profile by username or URL') and enumerates the returned fields, which cleanly distinguishes it from sibling profile-fragment tools like run_poshmark_users_followers and run_poshmark_users_items. It does not, however, explicitly contrast itself with run_poshmark_users_search or run_poshmark_items_search, so sibling differentiation is implicit rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is given, and no alternative is named despite a large family of sibling tools (run_poshmark_users_search, run_poshmark_users_followers, run_poshmark_users_items). The agent must infer selection purely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Followers of a Poshmark closet (handle, name, avatar), by username or URL. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| user | Yes | Username or closet URL. e.g. Username or closet URL, e.g. najescloset | |
| domain | No | Domain. Options: poshmark.com = poshmark.com, poshmark.ca = poshmark.ca | |
| max_items | No | Max followers (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the burden. It usefully discloses the pricing model ('1 point per returned record'), which is real behavioral value beyond the schema, but says nothing about pagination behavior, ordering, or rate limits, which matter here given the start_page and max_items parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two terse sentences, front-loaded with the resource and followed by the record shape and pricing note. Nothing wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does helpfully enumerate returned fields (handle, name, avatar), but it omits pagination semantics, result ordering, and any cap behavior beyond the schema's max_items constraint. Adequate but with clear gaps for a paged scraping tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all four parameters are already documented in the schema. The description adds only the 'by username or URL' input hint, which the schema's user description already covers. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb-less but unambiguous resource: followers of a Poshmark closet, plus the record fields returned (handle, name, avatar). It is clearly distinguishable from the many non-Poshmark siblings and from run_poshmark_users_items. It does not name its inverse sibling run_poshmark_users_following, so it stops short of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Only implied usage ('by username or URL'). It never states when to choose this over run_poshmark_users_following, run_poshmark_users_search, or run_poshmark_users, even though those are the plausible alternatives in the same family.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Users a Poshmark closet follows (handle, name, avatar), by username or URL. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| user | Yes | Username or closet URL. e.g. Username or closet URL, e.g. najescloset | |
| domain | No | Domain. Options: poshmark.com = poshmark.com, poshmark.ca = poshmark.ca | |
| max_items | No | Max following (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the output fields and a cost model ('1 point per returned record'), which is real behavioral context. It does not mention pagination behavior, auth needs, or the 500-item cap, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence that front-loads the resource and scope, followed by the returned fields and the cost note. No waste and nothing buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a list tool with no output schema: returned fields and cost are covered, and pagination parameters live in the schema. However it omits any hint about result ordering, the pagination interplay with start_page/max_items, or when this complements run_poshmark_users_followers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 user, domain, max_items, and start_page. The description's 'by username or URL' merely restates the user parameter that the schema already explains, adding no new syntax or format detail. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: the users a Poshmark closet follows, and enumerates the returned fields (handle, name, avatar). The 'following' scope inherently distinguishes it from run_poshmark_users_followers, though it never names that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives input guidance ('by username or URL') but no when-to-use context, no conditions for choosing this over run_poshmark_users, run_poshmark_users_followers, or run_poshmark_users_search, and no exclusions. Usage is only implied by the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Listings in a Poshmark closet by username or URL, with department, category, brand, size, color, price, condition, shipping, availability and sort filters. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Sizes (comma separated). e.g. 8, M | |
| sort | No | Sort by. Options: relevance = Relevance, just_in = Just in, price_low_to_high = Price: low to high, price_high_to_low = Price: high to low | |
| user | Yes | Username or closet URL. e.g. Username or closet URL, e.g. najescloset | |
| brand | No | Brand. e.g. Nike, Coach | |
| color | No | Colors | |
| domain | No | Domain. Options: poshmark.com = poshmark.com, poshmark.ca = poshmark.ca | |
| category | No | Category. e.g. Shoes, Dresses, Bags | |
| shipping | No | Shipping. Options: free = Free shipping, discounted = Discounted shipping | |
| condition | No | Condition. Options: all = All conditions, nwt = New with tags (NWT) | |
| max_items | No | Max items (up to 500) | |
| price_max | No | Max price | |
| price_min | No | Min price | |
| department | No | Department. Options: Women = Women, Men = Men, Kids = Kids, Home = Home, Electronics = Electronics, Pets = Pets, Beauty & Wellness = Beauty & Wellness | |
| start_page | No | Starting page | |
| subcategory | No | Subcategory. e.g. Athletic Shoes, Sneakers | |
| availability | No | Availability. Options: all = All, available = Available, available_and_dropping_soon = Available and dropping soon, dropping_soon = Dropping soon, sold = Sold, not_for_sale = Not for sale |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. 'Listings...' implies a read-only operation and '1 point per returned record' discloses the billing model, which the schema cannot express. However, pagination behavior (start_page, max_items capped at 500) and what a result record contains are never addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with zero filler: the resource and scope come first, followed by the filter surface and the cost note. Every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 16-parameter listing tool with no annotations and no output schema, the description covers the filter surface but omits pagination semantics, default/hard limits, and any sense of result shape or ordering guarantee.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the description only enumerates the same filter families (department, category, brand, size, color, price, condition, shipping, availability, sort) already documented per-property, with no added format or interaction guidance. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: listings in a Poshmark closet, scoped by username or URL. This clearly separates it from run_poshmark_items_search and run_poshmark_items (item-level lookup), though it never names those siblings explicitly to make the boundary unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says what the tool returns but gives no when-to-use guidance: it does not say to prefer this over run_poshmark_items_search when you already have a username, nor does it note any prerequisite (e.g. resolving a closet URL first) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Poshmark closets by name or handle (username, name, avatar, home region). 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Name or handle. e.g. najescloset | |
| domain | No | Domain. Options: poshmark.com = poshmark.com, poshmark.ca = poshmark.ca | |
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the pricing behavior (1 point per returned record), which is a real behavioral trait not in the schema. It omits pagination behavior, result caps relative to max_items, and whether misses still cost points.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, purpose front-loaded and the cost note appended with no filler. Efficient, though the cost sentence could be folded into a clearer usage line rather than standing alone.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-annotation, no-output-schema search tool this covers the essentials—what it searches, what the query matches, and the cost model. It still lacks sibling routing and any hint about the shape or volume of results, leaving the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the params are already documented and baseline is 3. The parenthetical clarifying that query matches username, name, avatar, and home region adds marginal meaning over the schema's 'Name or handle' example but does not explain domain or paging semantics further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (search Poshmark closets) plus the matchable fields (username, name, avatar, home region), which is more than a name restatement. However, it does not distinguish itself from the sibling run_poshmark_users, which an agent would need to route between.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance and no mention of the alternative run_poshmark_users for looking up a single known user. The only routing aid is the cost line, which hints at bulk search but doesn't set conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Products of a Product Hunt category: name, tagline, rating, review count, launches and categories. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Category slug or Product Hunt URL. e.g. productivity | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose a real behavioral trait not present in the schema: '1 point per returned record', i.e. the credit cost model. It says nothing about pagination behavior, rate limits, or auth, which leaves gaps for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short fragments with no filler, and the resource identity plus cost note are front-loaded. It is efficient, though the telegraphic style borders on under-specification rather than tightness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description compensates by enumerating the returned fields, which is genuinely useful. It still omits how max_items and start_page interact with the result set (i.e. pagination semantics), so it is adequate but not complete for a paged list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% – category (slug or URL), max_items (1-250), and start_page are all documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Products of a Product Hunt category' identifies the resource and scope, and the field list (name, tagline, rating, review count, launches, categories) confirms the payload. However, it is a noun fragment with no verb, and it does not distinguish itself from siblings like run_producthunt_categories_list (which presumably enumerates categories) or run_producthunt_products_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites, and no named alternative. An agent cannot tell from the text whether to reach for this tool versus run_producthunt_categories_list, run_producthunt_products, or run_producthunt_products_search when it wants products under a category.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The Product Hunt categories with their sub-categories: name, slug, parent and description. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose useful non-obvious context, namely that this is a read-style listing and that each successful run costs a flat 5 points, but it says nothing about auth requirements, rate limits, or whether results are paginated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with no filler; the payload description comes first and the cost note second. Nothing is wasted, though the opening noun fragment could have been tightened into a proper verb phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description compensates by enumerating the returned fields (name, slug, parent, description). For a zero-parameter read tool with a clear cost disclosure, this is nearly complete; only return shape/pagination details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics to explain. Schema coverage is 100% and the baseline for a no-param tool is 4; the description correctly omits any parameter discussion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (Product Hunt categories) and its contents (sub-categories plus name, slug, parent, description), so an agent can tell what it returns. However, it is a noun fragment with no verb and gives no signal to distinguish it from the near-identical sibling run_producthunt_categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool, no exclusions, and no reference to the many adjacent Product Hunt siblings such as run_producthunt_categories or run_producthunt_topics. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Products of a Product Hunt collection in the curator's order, with the full list paged beyond the first 20. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| max_items | No | Max items (up to 250) | |
| collection | Yes | Collection slug or Product Hunt URL. e.g. 0-design-tools | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden. It does disclose real behavior: results come back in curator order, pagination extends past the first 20, and there is a cost of '1 point per returned record.' That pricing and ordering context is genuinely useful, but there is nothing about pagination limits, rate limits, or record shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with what is returned before the paging and cost notes. Every clause carries information; only the terse '1 point per returned record' fragment reads a bit clipped.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must do more work, yet it only sketches the return set ('products ... in curator's order') without describing record fields or output shape. It is adequate for a list endpoint but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so collection, max_items and start_page are already documented in the schema. The description adds no extra meaning about parameter usage (e.g. how start_page interacts with the 'first 20', or that collection accepts a URL slug), so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb+resource: returns the products belonging to a Product Hunt collection, in the curator's order. This is specific enough to be actionable, but it never distinguishes itself from the sibling run_producthunt_collections_search, so an agent can't tell the two apart from the description alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'with the full list paged beyond the first 20' hints that this tool is for paginating the complete list, which implies usage, but no when-to-use statement or alternative (e.g. the collections_search sibling) is named. No prerequisites, no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse Product Hunt collections page by page, or search them by keyword. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No | Keyword (optional). e.g. design | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses a pricing rule ('1 point per returned record') and pagination behavior ('page by page'), but omits auth requirements, rate limits, return format, and error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loading the browse/search choice and appending the cost note. Every clause conveys purpose or a key operational trait, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-param read-only search with no output schema and no annotations, the description covers mode and cost but omits return shape, pagination interplay, and any explicit safety/read-only signal. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 keyword, max_items, and start_page. The description only indirectly references pagination and cost; it adds no format details or interaction semantics for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (browse/search) and resource (Product Hunt collections), making the tool's function clear. However, it does not distinguish this tool from the sibling run_producthunt_collections, which likely also browses collections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies optional keyword use for searching versus browsing page by page, giving some usage context. It does not specify when to choose this tool over run_producthunt_collections or other Product Hunt search siblings, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse Product Hunt forum threads page by page, or search them by keyword. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No | Keyword (optional). e.g. startup | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the cost model ('1 point per returned record') and confirms pagination behavior. It omits rate limits, whether keyword search is exact/partial, and any auth or result-shape context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the primary action and followed by the cost note. No filler; each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-param read tool with full schema coverage and no output schema, the description is mostly adequate. Its main gap is not differentiating from the overlapping run_producthunt_forums_threads sibling, which matters given the dense Product Hunt sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented with examples and bounds (max_items up to 250, start_page minimum 1). The description adds only the conceptual distinction of browsing vs. keyword search, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Browse Product Hunt forum threads page by page, or search them by keyword.' It clearly conveys two modes (browse and search). However, it does not distinguish itself from the sibling run_producthunt_forums_threads, which likely overlaps with the browsing mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use browse mode for paging through threads, or the keyword param to search. There is no explicit when-to-use/when-not guidance and no naming of the alternative run_producthunt_forums_threads, leaving the agent to infer selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top-level comments of a Product Hunt forum thread: text, author, votes, reply count and date, all pages. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| thread | Yes | Thread URL or forum/thread-slug. e.g. general/how-do-you-decide-what-features-should-be-free-and-what-should-be-paid | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does add two genuinely useful behavioral facts: it paginates across 'all pages' and bills '1 point per returned record.' However, it omits auth requirements, rate limits, and how 'all pages' interacts with the start_page/max_items parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the resource and follows with the returned fields and cost model; no wasted words. It stops just short of being maximally structured, but the economy is strong.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description does list the returned fields, which compensates somewhat. But for a paginated, billed scraping tool it should say more about auth, the all-pages vs. start_page interaction, and error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 three parameters (thread, max_items, start_page). The description adds no syntax or format detail beyond the schema, and its 'all pages' claim slightly tensions with the presence of a start_page parameter rather than clarifying it. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (top-level comments of a Product Hunt forum thread) and enumerates the returned fields, so an agent knows exactly what it fetches. It does not explicitly contrast itself with the sibling run_producthunt_forums_search, so it falls short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance, no exclusions, and no mention of the related run_producthunt_forums_search tool for discovering threads. The usage context (fetch comments for a known thread) is only implied by the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Product Hunt launch by slug or URL: tagline, votes, comments, daily / weekly / monthly rank, dates, topics, link and the product it belongs to. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| launch | Yes | Launch slug or Product Hunt URL. e.g. ship-os-by-notion |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: 'Get' implies a read-only lookup, the returned fields are enumerated, and the cost ('Flat 5 points per successful run') is disclosed. It does not cover not-found behavior or auth requirements, so it is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and then the returned fields, followed by the cost note. There is no filler, and every clause contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully lists the launch fields an agent can expect, which is the main completeness need here. It still omits failure behavior for invalid slugs/URLs, but covers the essential purpose and response content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the only parameter is already well documented in the schema. The description repeats that it accepts a slug or URL but adds no format or validation detail beyond the schema example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get one Product Hunt launch by slug or URL.' It names the entity and distinguishes this single-launch lookup from the many Product Hunt search/list siblings by requiring an identifier and returning one launch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is clear: call this when you already have a launch slug or Product Hunt URL. It does not explicitly name the alternative search tool for discovery, but the identifier-based usage condition is sufficiently clear to route an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Product Hunt launches by keyword: name, date and the product behind each launch. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Keyword. e.g. crm | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It does add one useful fact, the '1 point per returned record' cost signal, but says nothing about pagination behavior, result granularity, or permissions/auth needs for a search that supports start_page and max_items.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the resource and scope front-loaded, and the cost note is genuinely useful rather than filler. Nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description partially compensates by naming the returned fields. However, with no annotations, no alternative routing, and no mention of paging behavior for a paginated search, the definition is only minimally adequate for the surrounding Product Hunt tool family.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 keyword, max_items, and start_page fully, including the 250 cap. The description only restates the keyword dimension and adds no syntax, defaults, or paging semantics beyond what structured data already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search Product Hunt launches by keyword') and even enumerates the fields returned (name, date, product). It is clearly a keyword search rather than a listing, but it does not name or contrast with the sibling run_producthunt_launches, so an agent must infer the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use, when-not-to-use, or alternative routing guidance. With run_producthunt_launches, run_producthunt_products_launches, and run_producthunt_products_search all present, there is no signal telling the agent which one to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launches of a Product Hunt leaderboard (day, week, month or year): rank, name, tagline, votes, comments, topics and product link, beyond the first page. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date (daily 2024/1/15, weekly 2024/3, monthly 2024/3, yearly 2024). e.g. 2024/1/15 | |
| period | No | Period. Options: daily = Daily, weekly = Weekly, monthly = Monthly, yearly = Yearly | |
| featured | No | Featured only | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does add meaningful context: it discloses returned fields, notes pagination 'beyond the first page,' and states a cost of '1 point per returned record.' It does not specify read-only semantics, rate limits, or error behavior, but the cost and pagination details are valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that covers purpose, return fields, pagination, and cost without wasted text. Every phrase contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description lists the main return fields and explains pagination and per-record cost. It is largely complete for invocation, though it omits sibling differentiation and does not mention permissions or rate limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 five parameters, including the date format and period enum. The description reinforces the period concept and pagination but adds little parameter-level detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource: Product Hunt leaderboard launches for day, week, month, or year, and enumerates the returned fields. It is clear what the tool does, though it does not explicitly differentiate itself from sibling Product Hunt launch tools such as run_producthunt_launches or run_producthunt_launches_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for leaderboard retrieval but gives no explicit guidance on when to use this tool versus the many sibling Product Hunt tools. It also offers no exclusions or prerequisites, leaving alternative selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one product from Product Hunt by slug or URL: tagline, description, website, rating, review count, followers, launches, categories, social links, pros and cons, makers, awards and similar products. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product slug or Product Hunt URL. e.g. notion |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses two behavioral traits: the cost model ('Flat 5 points per successful run') and the shape of the returned payload. But it says nothing about error/failure behavior (e.g. invalid slug) or what 'successful' excludes, leaving a real gap for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and identifier before the payload listing and cost. The long field enumeration is slightly dense but every clause adds either scope or returned content, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description rightly enumerates the returned fields, covering that gap well. Missing pieces are behavioral: failure modes and auth/permission expectations, which matter given the absence of annotations, keeping it short of a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter's description already states 'Product slug or Product Hunt URL. e.g. notion'. The description's 'by slug or URL' merely restates that, adding no new syntax or format guidance, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one product from Product Hunt by slug or URL') and enumerates the returned fields. The singular 'one product' implicitly distinguishes it from run_producthunt_products_search, but no sibling is named explicitly, leaving differentiation to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The slug-or-URL trigger implies when to use it (you already know the product), which is adequate usage guidance. However, there is no explicit when/when-not statement and no reference to alternatives like run_producthunt_products_search for discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alternatives of a Product Hunt product with their rating and similarity score, all pages. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product slug or Product Hunt URL. e.g. notion | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that it fetches all pages and that it costs '1 point per returned record' – valuable cost/scope context. However, it omits any auth requirements, rate limits, or behavior when no alternatives exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the returned data front-loaded and the cost note second. No filler; every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter fetch tool with no output schema and no annotations, the description discloses the return fields and the per-record cost, which is enough to call it correctly. Only the lack of pagination interaction detail and auth notes keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so product, max_items, and start_page are already fully documented in the schema. The description adds no additional parameter meaning (e.g., how start_page interacts with max_items or the cost cap). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: retrieves alternatives of a Product Hunt product, and names the returned fields (rating, similarity score). It distinguishes itself from run_producthunt_products and run_producthunt_products_reviews by focusing on alternatives, though it doesn't explicitly route away from those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance and no named alternatives. 'all pages' hints at the scope of retrieval but does not tell the agent when this tool is preferable to run_producthunt_products or run_producthunt_products_search. Usage is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Customers of a Product Hunt product (products whose makers say they use it) with the shoutout note. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product slug or Product Hunt URL. e.g. notion | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose a genuine behavioral trait not present in structured data – the cost of '1 point per returned record' – but says nothing about pagination behavior, permissions, or the shape of the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no wasted words, and the resource definition is front-loaded. The trailing cost note is a distinct concern appended after the core statement, which slightly dilutes the focus.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter retrieval tool with full schema coverage and no output schema, the description covers what is returned and the cost. It omits pagination guidance, which matters given the max_items/start_page parameters, leaving a modest gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so product, max_items, and start_page are already documented in the schema (including the 250 cap and example slug). The description adds no additional parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource – the customers of a Product Hunt product – and disambiguates the term with 'products whose makers say they use it'. This is enough to separate it from sibling tools like run_producthunt_products_reviews or run_producthunt_products_alternatives, though the retrieval verb is only implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No indication of when to use this tool versus the many other run_producthunt_* tools, and no prerequisites or exclusions. The agent is left to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launches of a Product Hunt product: votes, comments, ranks and dates, all pages. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product slug or Product Hunt URL. e.g. notion | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose two useful behavior facts: pagination ('all pages') and a cost model ('1 point per returned record'). It omits auth/permission needs and whether it is a pure read, leaving gaps for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact fragments, front-loaded with the resource and return fields, followed by only the two extra facts (all pages, cost per record). No filler, though the colon-list style is slightly clipped.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with 100% schema coverage and no output schema, the description compensates by enumerating returned fields (votes, comments, ranks, dates) and noting pagination and cost. What remains missing is sibling routing guidance, which is a usage rather than completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so product, max_items and start_page are already documented in the schema (including the 250 cap and slug-or-URL format). The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource ('Launches of a Product Hunt product') and enumerates the returned fields (votes, comments, ranks, dates), so an agent knows this is a launch-history pull scoped to one product. It only partially separates itself from close siblings like run_producthunt_launches and run_producthunt_launches_search, relying on the 'of a product' scoping phrase rather than naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance or named alternatives despite a very crowded Product Hunt sibling set (run_producthunt_launches, run_producthunt_launches_search, run_producthunt_users_launches, run_producthunt_products). The agent must infer that 'product' scoping selects this tool over the platform-wide launch tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reviews of a Product Hunt product (all review types): rating, text, reviewer, date and alternatives mentioned, all pages. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product slug or Product Hunt URL. e.g. notion | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden, and it delivers two useful behavioral facts beyond the schema: 'all pages' (full pagination traversal) and '1 point per returned record' (cost/credit model). It still omits auth requirements and error/empty-result behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tightly-packed sentence that front-loads the resource and folds the return fields and cost note into the same clause with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description's enumeration of returned fields and the cost-per-record note are exactly the missing context an agent needs. It stops short of explaining page/item interaction or limits, but is largely complete for a read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so product, max_items, and start_page are already fully documented. The description adds no parameter-specific syntax or defaults (e.g. slug vs URL handling), so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Reviews of a Product Hunt product') and even enumerates the retrieved fields (rating, text, reviewer, date, alternatives mentioned), cleanly separating it from siblings like run_producthunt_products_alternatives or run_producthunt_products_launches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: an agent can infer it fetches product reviews, but there is no explicit when-to-use guidance, no mention of prerequisites, and no contrast against the many adjacent Product Hunt review-adjacent tools. Adequate but with a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Product Hunt products by keyword: name, tagline, rating, review count, logo and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Keyword. e.g. crm | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does add one genuine behavioral fact: '1 point per returned record', a cost signal that helps the agent budget calls. It also discloses the return fields, partially compensating for the absent output schema. However, it omits result ordering, pagination semantics, and any rate/permission context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, the primary purpose front-loaded, and the cost note placed last. Every element earns its place, with no rephrasing of the title or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter search tool with no output schema, the description usefully enumerates the returned record fields and flags per-record cost, which is exactly the information the missing output schema would otherwise supply. It is adequate for correct invocation, with only the when-to-use routing gap remaining.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% – keyword, max_items (1-250), and start_page are all documented in the schema. The description adds no parameter-level detail beyond restating the keyword-first model, so the baseline 3 applies; the structured fields do the work here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) plus resource (Product Hunt products) and the input mode (by keyword), so the agent can tell this apart from retrieval-style siblings like run_producthunt_products. It also enumerates the returned fields (name, tagline, rating, review count, logo, link), which sharpens what the tool yields. It does not explicitly contrast itself with the many sibling search tools, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies keyword-driven usage but gives no explicit when-to-use guidance, no prerequisites, and never names an alternative (e.g. run_producthunt_products vs run_producthunt_products_search). The only supplementary cue is the cost note, which is not usage routing. An agent must infer selection from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Products of a Product Hunt topic: name, tagline, rating, review count, launches and categories. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Topic slug or Product Hunt URL. e.g. artificial-intelligence | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose a genuinely useful behavioral trait not derivable from schema or annotations: the '1 point per returned record' cost model, which lets an agent reason about budget. It still omits read-only safety framing, pagination/ordering behavior, and any rate-limit or auth context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with no filler, and the resource scope is front-loaded ahead of the cost note. The return-field enumeration is slightly list-like but each item is information-bearing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description partially compensates by listing returned fields (name, tagline, rating, review count, launches, categories) and the cost model. It still leaves the result envelope, ordering, and pagination semantics unstated for a tool whose parameters imply paging.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (topic slug/URL, max_items up to 250, start_page are all documented inline), so the baseline is 3. The description adds no syntax or constraint detail about the parameters beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb+resource: products belonging to a Product Hunt topic, and enumerates the returned fields. That distinguishes it from run_producthunt_categories and run_producthunt_categories_list, which are topic/category-level rather than product-level. It does not, however, name those siblings explicitly to remove all doubt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over run_producthunt_products, run_producthunt_products_search, or run_producthunt_launches. The agent must infer 'topic in, products out' entirely from the name and schema, with no stated prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Product Hunt user by username or URL: name, headline, about, followers, submitted launches, products, collections, reviews, links and join date. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| user | Yes | Username or Product Hunt profile URL. e.g. kevin |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the flat cost ('5 points per successful run') and lists what comes back, implying a read-only profile fetch, but it says nothing about error behavior for a missing user, auth requirements, or whether the response is paginated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the purpose and the returned fields, with the cost note appended. The field enumeration is long but earns its place given there is no output schema; there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description supplies the input contract, the returned field set, and the cost, which is close to everything needed. Missing only guidance on failure modes and usage context relative to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'user' parameter, already documenting that it accepts a username or Product Hunt profile URL with an example. The description repeats this acceptance without adding format or normalization detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one Product Hunt user by username or URL') and enumerates the returned profile fields, so the agent can tell it is the single-profile lookup. It does not explicitly name the sibling sub-resource tools (run_producthunt_users_launches, _comments, _stacks, _upvotes), so full sibling differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is given, and no alternative is named. Usage is only implied by 'Get one ... user', which an agent must interpret against the many related Product Hunt user sub-resource tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Collections of a Product Hunt user with their size and first products, all pages. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| user | Yes | Username or Product Hunt profile URL. e.g. kevin | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It does disclose two genuine behavioral traits beyond the schema: pagination over all pages and the credit cost model ('1 point per returned record'), which is valuable for tool selection. However it says nothing about auth, rate limits, or failure behavior, leaving notable gaps for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the resource and its contents, then the cost note. Every clause carries information; nothing is padded. Slightly terse rather than wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so by naming what each collection entry contains ('size and first products'). Combined with the pagination and cost notes, an agent has enough to call it correctly, though permission/auth context is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (each of user, max_items, start_page is documented with type and examples), so the baseline is 3. The description adds no parameter-level detail such as pagination interaction between start_page, max_items, and 'all pages', so it neither helps nor hurts beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource scoped to a Product Hunt user ('Collections of a Product Hunt user') and adds what the records contain ('size and first products') plus scope ('all pages'). It implicitly distinguishes itself from the global run_producthunt_collections by the user scoping, but never names that sibling explicitly, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied through the 'of a Product Hunt user' entity scoping; there is no explicit when-to-use statement and no named alternative (e.g. run_producthunt_collections for site-wide collections) to route the agent. Adequate but leaves selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Comments of a Product Hunt user, taken from their activity feed (comments filter), all pages. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| user | Yes | Username or Product Hunt profile URL. e.g. kevin | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose useful behavior: sourcing from the comments-filter activity feed, fetching across all pages, and a '1 point per returned record' cost. It omits auth requirements, rate limits, and error behavior, so it only partially covers the non-annotated burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight clauses with the resource front-loaded and the cost note at the end; there is essentially no filler. It could be marginally sharper with an explicit scope statement, but it is well-sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should ideally hint at the shape of returned comment records; it only says comments are returned 'all pages' with per-record cost. Adequate for a straightforward scraper, but the record structure is left entirely unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (user, max_items, start_page all documented including formats and bounds). The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (comments of a Product Hunt user) plus its provenance (activity feed, comments filter). This cleanly distinguishes it from siblings like run_producthunt_users_upvotes, run_producthunt_users_launches, and run_producthunt_users_stacks, so an agent can pick it without opening another schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the resource name and the activity-feed source, but the description never states when to choose this over its Product Hunt user siblings or what prerequisites exist. No explicit when/when-not guidance or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launches submitted by a Product Hunt user: votes, comments, ranks and dates, all pages. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| user | Yes | Username or Product Hunt profile URL. e.g. kevin | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the fields returned (votes, comments, ranks, dates), that all pages are fetched, and the cost model ('1 point per returned record') – genuinely useful. However it omits auth requirements, rate limits, and failure behavior for a scraping-style tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences, front-loaded with the resource and scope, followed by the cost note. No filler, though the sentence is somewhat dense with the field list and billing clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description partially compensates by naming returned fields and the per-record cost. For a multi-page scrape with no annotations, though, it should say more about auth and pagination controls to let an agent call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents user, max_items and start_page. The description adds only the 'all pages' pagination hint, which loosely relates to start_page/max_items but adds no syntax or format detail. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: launches submitted by a Product Hunt user, with the returned fields enumerated. It doesn't explicitly differentiate from close siblings like run_producthunt_users_upvotes or run_producthunt_users_comments, but the resource naming makes the distinction inferable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use, when-not-to-use, or named alternative. Given the dense set of run_producthunt_users_* siblings (upvotes, comments, collections, stacks), it should say which one to pick for what, but leaves this entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Products in a Product Hunt user's stack with who recommended them. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| user | Yes | Username or Product Hunt profile URL. e.g. kevin | |
| max_items | No | Max items (up to 250) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries full behavioral burden. It discloses a useful cost trait ('1 point per returned record'), but says nothing about pagination, ordering, permissions, or what the stack/recommender records actually contain at a behavioral level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, resource described first, cost note second, zero filler. Front-loaded and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool with no output schema, the description communicates the returned entity ('products ... with who recommended them') and a cost hint, which is most of what an agent needs. It lacks routing context against the large Product Hunt sibling set and any return-shape detail, keeping it short of a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (user and max_items are both documented, with an example and a 250 cap), so the schema does the heavy lifting. The description adds nothing about parameter semantics beyond what the schema already states; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb-less but resource-specific statement: what the tool returns (products in a Product Hunt user's stack) plus the enrichment (who recommended them). It names a distinct resource ('stacks') that separates it from generic Product Hunt user tools, but it does not explicitly differentiate from near siblings like run_producthunt_users_collections or run_producthunt_users_upvotes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No statement of when to use this over alternatives. Given the dense cluster of run_producthunt_users_* siblings, an agent gets no routing guidance, only implied usage from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launches a Product Hunt user upvoted, newest first: votes, comments, ranks and dates. The site serves at most the latest 200 upvotes of a user. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| user | Yes | Username or Product Hunt profile URL. e.g. kevin | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does reasonably well: it discloses the newest-first ordering, the site-imposed 200-upvote ceiling, the returned fields (votes, comments, ranks, dates), and the cost model (1 point per record). It does not explain how start_page/max_items interact with the 200 cap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the core action and the critical cap front-loaded. No filler, though the phrasing 'Launches a Product Hunt user upvoted' is slightly awkward.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema and no annotations, the description covers returned fields, ordering, scope cap, and pricing. The main omission is how pagination parameters behave against the 200-record ceiling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented. The description adds ordering context ('newest first') but no syntax or format detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: returns the launches a Product Hunt user upvoted, with ordering and returned fields. It is distinguishable from siblings such as run_producthunt_users_launches (launches by user) by the 'upvoted' framing, though it never explicitly names that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus similar Product Hunt user tools, and no exclusions. The only contextual note is the 200-upvote cap, which is a constraint rather than a selection criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Portugal registry (Registo Comercial publications portal) by NIF/NIPC or registry link: name, legal form, registered seat (street, postal code, locality, parish, municipality, district), number of publications and the newest publication. 15 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | NIF/NIPC or registry URL. e.g. 500697256 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it does disclose two real traits: the cost ('15 point per returned record') and the full set of returned fields, which matters because there is no output schema. It omits auth requirements and not-found/error behavior, keeping it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence delivers source, key, return shape, and pricing with no filler. The parenthetical seat breakdown is slightly dense but every element is meaningful, so nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, enumerating the returned fields (name, legal form, seat components, publication count, newest publication) is valuable and largely compensates. Cost per record is covered, but error/not-found behavior and any input-normalization guidance are absent for a lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is fully documented in the schema (including the example 500697256). The description's 'NIF/NIPC or registry link' essentially restates the schema, adding no format, normalization, or validation detail beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (get one company from the Portugal registry) plus the exact lookup key (NIF/NIPC or registry link) and enumerates the returned fields. This implies a single-record lookup versus the sibling run_pt_companies_search, but it never names that sibling or explicitly draws the line, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer you call this when you already hold a NIF/NIPC or registry URL. There is no explicit when-to-use statement, no mention of the run_pt_companies_search alternative, and no note on what to do if you only have a company name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Portugal company registry (Registo Comercial publications portal) by entity name: name, NIF/NIPC, municipality and the date and type of the newest publication. 2 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Company name. e.g. padaria | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page (25 companies per page) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it discloses one genuinely useful behavioral trait: the '2 point per returned record' credit cost, which the schema does not mention. Beyond that it says nothing about permissions, rate limits, or how pagination interacts with cost, so the behavioral profile remains thin for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact, front-loaded with the verb and resource, and the cost note is a short trailing clause. The middle list ('name, NIF/NIPC, municipality and the date and type...') is slightly tangled because it reads as a facet list but is actually output fields, costing it the top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only 3 parameters at full schema coverage and no output schema, the description helpfully sketches the return fields, which partly compensates for the missing output schema. But it omits the pagination model (25 per page) that an agent needs to iterate results, and gives no guidance on sibling selection, leaving it only adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 keyword, max_items, and start_page, which sets the baseline at 3. The description's phrase 'by entity name' loosely reinforces that keyword is a name, but it muddies this by listing NIF/NIPC and municipality, which are not input parameters — it adds little clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb and resource ('Search the Portugal company registry') and even enumerates the returned fields (name, NIF/NIPC, municipality, newest publication date/type). However, it does not distinguish this tool from its close siblings run_pt_companies and run_pt_company_filings, so an agent cannot tell from the description alone which Portugal variant to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this search variant versus the sibling run_pt_companies or run_pt_company_filings, and no prerequisites or exclusions. The reader must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the publications of a Portugal company (Registo Comercial publications portal) by NIF/NIPC or registry link, newest first: date, act type (registry acts, accounts deposits, notices, convocations), municipality and whether a text / attachment exists. 2 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | NIF/NIPC or registry URL. e.g. 500697256 | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page (80 publications per page) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does deliver: it discloses sort order (newest first), enumerates the returned fields (date, act type, municipality, text/attachment presence), and even states a cost ('2 point per returned record'). It omits pagination/rate-limit behavior beyond the schema, but the operational context is far richer than a bare listing statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, then a compact enumeration of return fields and the per-record cost. The colon-heavy single sentence is dense but every clause (fields, ordering, act types, cost) adds information; nothing appears to be filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description usefully compensates by listing the fields a result contains and the ordering. For a read-only, three-parameter listing tool this is largely complete; only pagination mechanics and result volume limits are left to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented in the schema. The description restates the 'company' input ('by NIF/NIPC or registry link') but adds no format or constraint detail for max_items or start_page beyond what the schema already provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and resource ('publications of a Portugal company'), scoped to the Registo Comercial portal. It is clearly distinguishable from sibling company tools like run_pt_companies and run_pt_companies_search, which return company data rather than publication records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description identifies the accepted lookup keys ('by NIF/NIPC or registry link') and the source portal, which implies usage, but it never states when to prefer this tool over alternatives such as run_pt_companies_search or how to obtain the identifier first. Usage is inferable but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rakuten Ichiba genre tree: the top-level genres, or one genre by id with its breadcrumb path and child genres (with item counts). Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| genre_id | No | Genre ID (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses output content (breadcrumb path, child genres with item counts) and the cost model ('Flat 5 points per successful run'), which is genuinely beyond structured fields. It says nothing about pagination, rate limits, or error behavior, so the disclosure remains partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the resource and modes before the cost note. No filler, no repetition of the tool name or title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-optional-param lookup with no annotations and no output schema, the description covers both invocation modes, the returned structure, and the cost. Error and limit behavior are unaddressed, which is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already labels genre_id as 'Genre ID (optional)', but the description adds real meaning by stating what omitting vs. supplying it returns. That behavioral mapping of the parameter exceeds the baseline for a schema-covered single param.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Rakuten Ichiba genre tree') and spells out both operating modes: top-level genres, or a single genre by id with breadcrumb path and child genres. An agent can distinguish this from sibling category tools like run_olx_categories or run_ebay_category without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly communicates the selection condition — omit genre_id to browse the tree, supply it to get one genre with breadcrumb and children. However, it names no alternatives or exclusions (e.g., when to reach for run_rakuten_items_search instead), so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Rakuten Ichiba item by shop_code/item_code or URL: price range, subscription price, points, shipping, images, rating, category, shop and SKU variants. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| item | Yes | Item (shop_code/item_code) or URL. e.g. sawaicoffee-tea/ac-sale-1960 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It genuinely adds value by disclosing the cost model ('Flat 5 points per successful run') and sketching the response payload. It does not cover failure behavior, auth requirements, rate limits, or what happens when the identifier is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence with the resource lookup front-loaded and cost trailing. The field enumeration is long but each item is informative. No filler sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description correctly compensates by enumerating the returned fields (price range, subscription price, points, shipping, images, rating, category, shop, SKU variants), plus the cost per run. For a one-parameter detail tool this is close to sufficient, though error/edge behavior is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'item' parameter already documents the shop_code/item_code format with an example. The description reinforces the same accepted format (shop_code/item_code or URL) but adds no syntax or edge-case detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get) and resource (one Rakuten Ichiba item), and enumerates the fields returned (price, points, shipping, rating, SKU variants), so an agent immediately knows this is a single-item detail lookup. It does not explicitly name the sibling run_rakuten_items_search, but 'one item' strongly implies detail vs. search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by shop_code/item_code or URL' implies the tool is used when you already hold a specific item identifier, which is meaningful usage context. However, it never states when to use this vs. run_rakuten_items_search or run_rakuten_shops_items, nor any prerequisites. Usage is implied rather than prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Customer reviews of a Rakuten Ichiba item by shop_code/item_code or URL: rating, text, author, dates, helpful count, purpose tags, SKU, media and shop replies. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| item | Yes | Item (shop_code/item_code) or URL. e.g. sawaicoffee-tea/ac-sale-1960 | |
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It usefully discloses the return fields (rating, text, author, dates, helpful count, purpose tags, SKU, media, shop replies) and the cost model ('1 point per returned record'), which is real behavioral value. However it says nothing about auth requirements, rate limits, or pagination behavior beyond what the schema exposes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the core resource and then enumerates return fields plus cost. Every clause carries information; only the field enumeration is slightly list-heavy. Well sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description compensates by naming the returned fields and the point cost, which is what an agent needs to decide to call it. Pagination semantics (start_page/max_items interplay) are left to the schema, a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (item, max_items, start_page) are already documented. The description's 'by shop_code/item_code or URL' mirrors the schema's item description rather than adding new meaning. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Customer reviews of a Rakuten Ichiba item,' and lists the fields returned, so an agent can distinguish it from run_rakuten_items or run_rakuten_items_search. It does not explicitly name those siblings, but the 'reviews' framing makes the scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description (fetch reviews for a given item), but there is no explicit when-to-use vs when-not guidance and no alternative named among the many review tools (run_newegg_products_reviews, run_walmart_product_reviews, etc.) or the sibling run_rakuten_shops_items. Adequate but leaves routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search live Rakuten Ichiba items by keyword with sort, condition, price range and genre filters. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: relevancy = Relevancy, price_low_to_high = Price: low to high, price_high_to_low = Price: high to low, newest = Newest, review_count = Most reviews, review_score = Best review score | |
| keyword | Yes | Search term. e.g. コーヒー豆 | |
| genre_id | No | Genre ID | |
| condition | No | Condition. Options: new = New, used = Used | |
| max_items | No | Max items (up to 500) | |
| price_max | No | Max price (JPY) | |
| price_min | No | Min price (JPY) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully adds that results are live and that billing is 1 point per returned record, but it does not describe authentication, rate limits, pagination behavior, or the shape of returned records.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences with the primary purpose front-loaded and no wasted language. The pricing note is short and operationally relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema fully covers the eight parameters, but there is no output schema and no annotations. The description explains the search purpose and cost but omits what a returned record contains, how pagination behaves, and when to prefer this over related Rakuten tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented in the input schema. The description names the major filter categories (sort, condition, price range, genre) but adds no syntax, defaults, or constraints beyond the schema, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: searching live Rakuten Ichiba items by keyword, with filters named. This clearly separates it from a detail lookup, but it does not explicitly name sibling alternatives such as run_rakuten_items or run_rakuten_shops_items, so it falls short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase "Search live Rakuten Ichiba items by keyword" implies the tool is for keyword-based item discovery and supplies some filter context. However, it gives no explicit when-to-use versus run_rakuten_items or run_rakuten_shops_items, and no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Rakuten Ichiba shop storefront by shop_code or URL: name, description, logo, cover, rating and review count. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| shop | Yes | Shop code or URL. e.g. sawaicoffee-tea |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses a cost trait ('Flat 5 points per successful run') and implies a read-only single-record fetch, but says nothing about failure behavior, auth requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the core purpose and return fields, with the cost note trailing. Nothing is wasted, though the field enumeration could be trimmed given no output schema exists to compete with it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema and no annotations, the description covers the input semantics, the returned fields, and the cost model. Only missing element is explicit routing against sibling Rakuten tools, which keeps it out of the top band.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already documents the 'shop' parameter as 'Shop code or URL' with an example. The description's 'by shop_code or URL' repeats that without adding format, validation, or fallback details, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get') and resource ('one Rakuten Ichiba shop storefront') and enumerates the returned fields, so the agent knows exactly what it retrieves. It doesn't explicitly contrast itself with the many sibling tools like run_rakuten_shops_items or run_rakuten_items, but 'shop storefront' is clearly distinct from item/category tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the single-shop scope and the accepted shop_code/URL input, but there is no explicit when-to-use or when-not-to-use guidance and no named alternative (e.g., run_rakuten_shops_items for a shop's products). The agent must infer routing from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The item catalog of a Rakuten Ichiba shop by shop_code or URL: title, price range, image, points, shipping, rating, category. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| shop | Yes | Shop code or URL. e.g. sawaicoffee-tea | |
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses cost ('1 point per returned record') and enumerates the returned fields, but omits read-only confirmation, auth requirements, pagination behavior, and rate limits that would matter for a 500-item-max retrieval call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the purpose first, followed by a short cost note; nothing is padded. The inline field list is dense but serves the reader given there is no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with full schema coverage but no output schema, the description competently compensates by naming the returned fields. Missing items are minor: no mention of pagination behavior (start_page/max_items interplay) or maximum result semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are documented in the schema with examples and bounds. The description adds no parameter detail beyond repeating the shop_code-or-URL input already covered by the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (the item catalog of a Rakuten Ichiba shop) and scopes it by shop_code or URL, so an agent knows exactly what it retrieves. It does not explicitly differentiate itself from siblings like run_rakuten_items or run_rakuten_items_search, so sibling routing is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description never says when to use this tool versus alternatives such as run_rakuten_items_search or run_rakuten_shops, nor does it state any preconditions. It only describes what is returned, leaving the agent to guess at the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Romania registry data (Ministry of Finance / ONRC) by CUI (CIF): name, status and registration date, address, trade register number, authorization act, phone/fax, tax registrations (profit tax, VAT, social contributions, ...) and the latest filed financial indicators (assets, debts, equity, turnover, profit, employees). 15 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | CUI (CIF). e.g. 2816464 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the cost ('15 point per returned record') and the data fields returned, but says nothing about failure/not-found behavior, auth needs, or rate limits for a live registry lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that opens with the action and resource before the long field list. The field enumeration is dense but earns its place by standing in for the missing output schema; minor bloat from the trailing '...'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup with no output schema, the description compensates well by enumerating the returned fields and stating the credit cost. It leaves error/not-found behavior unaddressed, which keeps it short of full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter with 100% schema description coverage, and the schema already gives the CUI example (2816464). The description's restatement of CUI (CIF) adds no syntax or format detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (get one company) scoped to the Romania registry and keyed by CUI (CIF), then enumerates the returned fields. It implicitly distinguishes itself from run_ro_companies_search by being a single-record identifier lookup, but never names the sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The identifier requirement ('by CUI (CIF)') implies usage when a company ID is already known, but the description never states when to prefer this over run_ro_companies_search or what to do without a CUI. Guidance is inferable rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Romania company registry (Ministry of Finance / ONRC data) by company name: name and CUI. Bucharest by default, add "@ cluj" (county name or code) to the keyword to search another county. All words must appear in the name. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Company name (optionally @ county). e.g. dedeman | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It usefully discloses the default county scope, the all-words-must-match behavior, and a cost signal ('1 point per returned record'). It omits pagination behavior, rate limits, and auth requirements, which leaves meaningful gaps for a registry query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, then the county default and syntax, then matching semantics and cost. Every clause carries information; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-annotation, no-output-schema search tool, the description covers purpose, default scope, query syntax, matching rules, and cost. Only pagination/return-format guidance is absent, which is minor given start_page and max_items are documented in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds genuine value beyond the schema: it explains the '@ county' syntax in detail (county name or code), states the Bucharest default, and clarifies that all words must appear in the name. The schema's keyword description is far terser ('optionally @ county').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search), a precise resource (Romania company registry), and even the underlying data source (Ministry of Finance / ONRC). An agent immediately knows this is the Romanian company lookup, distinguishable from the many other country registries and the generic run_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives actionable usage detail for the county dimension (Bucharest by default, add '@ cluj' for another county) and matching semantics (all words must appear). However, it never states when to use this versus the sibling run_ro_companies (the non-search lookup) or when-not to use it, leaving sibling selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs a web search and returns a structured search payload.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| settings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet it discloses almost nothing: no rate limits, auth requirements, pagination, result caps, or which search backend is used. 'Returns a structured search payload' is the only behavioral hint, and with no output schema the agent still cannot anticipate the return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is front-loaded and free of padding, which is structurally sound. But it is terse to the point of under-specification rather than genuinely concise, so it does not fully earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, 0% parameter documentation, and a nested settings object, the definition leaves major gaps for a tool sitting among hundreds of siblings. An agent cannot determine what this tool searches, how it differs from run_extract, or what the payload contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description explains neither of the two parameters. In particular the nested 'settings' object (country, language, max_results) is entirely undocumented, so the agent gets no syntax, format, or default information beyond the bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Runs') and resource ('web search'), which is clearer than a tautology. However, it offers no differentiation from adjacent siblings like run_extract or the many domain-specific search tools, so an agent cannot tell why this generic search should be preferred over run_extract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no mention of when this generic search is preferable to the numerous sibling search tools (e.g., run_extract, run_linkedin_people_search), and no prerequisites or exclusions. The agent is left to infer everything about routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Sweden registry (Bolagsverket) by organisation number or registry link: name, status history, registration date, address, legal form, municipality and county, special and foreign-language business names. 5 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Organisation number or registry URL. e.g. 556012-5790 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose a cost model ('5 point per returned record') plus the full field inventory that comes back. It doesn't state read-only semantics, permission requirements, or error behavior for an unknown org number, so it stops short of full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence led by the verb and lookup key, with the returned-field inventory and cost appended. Every clause is informative given the absence of an output schema, though the long field enumeration is dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description compensates by enumerating the returned fields and the per-record cost, which is what an agent needs for a single-identifier lookup. Only edge cases (invalid identifier, rate limits, auth) are unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already gives the format example (556012-5790), so the baseline is 3. The description restates the accepted identifier types ('organisation number or registry link'), adding mild reinforcement but no syntax detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get one company') and resource ('Sweden registry (Bolagsverket)') plus the exact lookup keys (organisation number or registry link). The singular 'one company' versus the sibling run_se_companies_search's plural search semantics is clear without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by organisation number or registry link' tells the agent the precondition for calling this tool (you must already hold an identifier), which implicitly routes it away from the search sibling. It never names run_se_companies_search explicitly or states when not to use this, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Sweden company registry (Bolagsverket) by company name or organisation number: name, organisation number, status, city, legal form and card link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Company name. e.g. volvo | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the pricing model ('1 point per returned record') and enumerates the returned data points, but says nothing about authentication, rate limits, or how pagination affects results. It adds some behavioral value without being complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence plus a short cost note; the registry, search keys, and output fields come first with no filler. The field enumeration is slightly dense but each item is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description appropriately enumerates the returned fields (name, organisation number, status, city, legal form, card link) and states the per-record cost. Pagination behavior is left to the schema's start_page/max_items, which is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 keyword, status, max_items, and start_page. The description restates search-by-name/org-number and result fields but adds no syntax or format detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (Sweden company registry / Bolagsverket) scoped to Sweden, and lists the fields searched and returned. It clearly separates this from the many other country company-search siblings, but it never explicitly distinguishes itself from the sibling run_se_companies, which an agent could confuse for the same registry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'by company name or organisation number' hints at the search inputs, but there is no explicit when-to-use, when-not, or pointer to alternatives such as run_se_companies (detail lookup) versus this search tool. The agent must infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the most recent registry cases of a Sweden company (Bolagsverket) by organisation number or registry URL, newest first: case number, type (annual report, interim report, register update...), status, arrival and registration dates, financial period. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Organisation number or registry URL. e.g. 556012-5790 | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose useful behavior: results are newest-first, the record shape is enumerated, and the cost model ('1 point per returned record') is stated — an important budget signal. It omits pagination semantics (how start_page interacts with max_items) and behavior when the company identifier resolves to nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence leads with the verb and resource, then the identifier options, ordering, and output fields, with the cost note appended. Given there is no output schema, the field enumeration earns its place; there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully documents the returned fields and their order, and it discloses cost. Remaining gaps are pagination behavior and error/empty-result handling, which an agent would need when paging through up to 250 items.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented. The description restates that company accepts an organisation number or registry URL, which the schema already says, and adds nothing about max_items or start_page. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (most recent registry cases of a Sweden company via Bolagsverket), plus ordering and the fields returned. An agent can distinguish this from run_se_companies because it is about filings/cases rather than company profile data, though the description never names the sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the resource: call it when you need filing history for a Swedish company identified by org number or registry URL. There is no explicit when-to-use/when-not guidance and no routing to run_se_companies or run_se_companies_search for basic company data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one funded business from the Republic Europe (Seedrs) secondary-market page by slug or URL: description, sector, available shares, indicative valuation and its change, eligibility and incorporation date. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| business | Yes | Business slug or URL. e.g. revolut |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the returned payload (description, sector, available shares, valuation and its change, eligibility, incorporation date) and the cost ('Flat 5 points per successful run'), but never states that it is a read-only fetch, nor any auth or rate-limit behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and source, with the returned-field list and cost appended. Dense but every clause carries information; only the enumeration gets close to over-stuffing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must describe returns — and it does so thoroughly for a single-parameter fetch. Missing only the read-only/permission context, which is minor for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is already documented ('Business slug or URL. e.g. revolut'). The description's 'by slug or URL' merely restates the schema rather than adding format or edge-case detail, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one funded business from the Republic Europe (Seedrs) secondary-market page by slug or URL') and enumerates the returned fields. This cleanly distinguishes it from the sibling run_seedrs_campaigns (campaigns) and run_seedrs_campaigns_search without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'by slug or URL' — the agent learns it needs a pre-existing identifier — but there is no explicit statement of when to use this versus run_seedrs_campaigns or the search variant, nor any prerequisite or exclusion. Adequate but with a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Republic Europe (Seedrs) campaign by slug or URL: raised and target amounts, valuation, equity offered, share price, investors, tax relief, company number, sectors, links, highlights and the pitch text. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| campaign | Yes | Campaign slug or URL. e.g. athena-ai |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses this is a read-style retrieval ('Get'), enumerates the returned fields in detail (a real substitute for the missing output schema), and even notes the cost ('Flat 5 points per successful run'). It omits auth requirements, rate limits, and failure behavior for bad slugs, leaving gaps for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and identifier format, then the return payload and cost. The field enumeration is long but earns its place by compensating for the absent output schema; there is little waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter get-by-identifier tool with no output schema, the description covers the action, input format, and a thorough list of returned data, so an agent knows what it will receive. Missing only peripheral details like auth or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single param is already documented with an example ('athena-ai'), so the schema does the heavy lifting. The description's 'by slug or URL' merely reinforces the accepted identifier formats without adding syntax or edge-case detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get) and resource (a Republic Europe/Seedrs campaign) scoped to a single record ('one campaign by slug or URL'), which implicitly distinguishes it from the run_seedrs_campaigns_search sibling. However, it never names that sibling explicitly, so the differentiation is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by slug or URL' implies the caller must already have an identifier, hinting that a search step may be needed first, but there is no explicit when-to-use guidance or named alternative (e.g. run_seedrs_campaigns_search). Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the live Republic Europe (Seedrs) campaigns by campaign-name word and sector, impact tag, business type, tax relief and pitch type filters: raised and target amounts, valuation, investors, type, status and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: trending_desc = Trending (default), trending_asc = Trending (least first), most_recent_desc = Most recent, most_recent_asc = Oldest, percentage_raised_desc = Most raised (%), percentage_raised_asc = Least raised (%), closing_date_asc = Closing soonest, closing_date_desc = Closing latest, business_name_asc = Name A-Z, business_name_desc = Name Z-A, valuation_desc = Valuation (high first), valuation_asc = Valuation (low first), investment_sought_desc = Target (high first), investment_sought_asc = Target (low first), investors_count_desc = Investors (most first), investors_count_asc = Investors (least first) | |
| tags | No | Impact | |
| types | No | Pitch type | |
| search | No | Campaign name word. e.g. skytree | |
| sectors | No | Sectors | |
| max_items | No | Max items (up to 250) | |
| trending_in | No | Trending in (country code). e.g. GB | |
| business_types | No | Business type | |
| include_prereg | No | Include pre-registration pages | |
| tax_eligibilities | No | Tax relief |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that only live campaigns are searched and that billing is '1 point per returned record' — a real cost signal. It does not disclose pagination/default result count behavior or any rate limits, leaving a gap for a 10-parameter search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and resource before listing facets and outputs — no wasted preamble. It is dense and slightly overloaded at the tail (returned-field list), but every element is informative given there is no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All 10 parameters are optional and fully documented in the schema, and the description compensates for the absent output schema by naming the return fields (raised/target amounts, valuation, investors, type, status, link). Only default result-count and paging behavior remain undeclared, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 every parameter and the full sort enum. The description restates the filter categories and the returned fields, adding marginal mapping value but no syntax, format, or combination guidance beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Search') plus a precisely scoped resource ('live Republic Europe (Seedrs) campaigns'), and enumerates the filterable facets (name word, sector, impact tag, business type, tax relief, pitch type) and the fields returned. This distinguishes it from the sibling run_seedrs_campaigns (single campaign lookup) and run_seedrs_businesses without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'live' implies results are restricted to active campaigns, and the facet list implies this is the discovery tool versus run_seedrs_campaigns for a known campaign. However, it never explicitly states when to prefer this over run_seedrs_campaigns or run_seedrs_businesses, nor any prerequisite or exclusion. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Shopify collection by store domain and handle: title, description, image, product count and timestamps. 5 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| collection | Yes | Collection handle or URL. e.g. mens | |
| store_domain | Yes | Store domain. e.g. gymshark.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the returned fields (title, description, image, product count, timestamps) and a cost signal ('5 point per returned record'), which is useful, but it says nothing about auth requirements, rate limits, error behavior on a missing handle, or whether the lookup is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action and followed by the returned payload. Every clause carries information, though the trailing '5 point per returned record' phrasing is slightly awkward.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool with no output schema, the description compensates by enumerating return fields and noting cost, but it omits failure modes, auth context, and how the single record is scoped. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented. The description adds only that the collection is identified 'by store domain and handle', which mildly reinforces the schema (which actually allows a handle or URL) without adding syntax or format detail. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get) and resource (one Shopify collection), and specifies the retrieval keys (store domain and handle). It clearly distinguishes fetching a single collection from product-listing siblings, though it never names run_shopify_collections_products as the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, prerequisites, or alternatives are given. An agent cannot tell from the text when to prefer this over run_shopify_collections_products or run_shopify_products_search; usage is only implied by the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Products of a Shopify collection with options, variants, prices and availability. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| max_items | No | Max items (up to 500) | |
| collection | Yes | Collection handle or URL. e.g. mens | |
| start_page | No | Starting page | |
| store_domain | Yes | Store domain. e.g. gymshark.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It does add one genuinely useful behavioral fact, the credit cost of 1 point per returned record, but says nothing about pagination behavior, the 500-item cap, store/domain requirements, failure modes for invalid handles, or what availability means.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler, and the resource being fetched is front-loaded. Nothing is padded, though the second sentence is a bare cost note rather than a structural aid.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description partially compensates by naming return fields (options, variants, prices, availability). However, it omits pagination/results-window guidance and collection-resolution behavior, leaving it only minimally sufficient for a 4-parameter scraping tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with every parameter documented in-schema (collection handle/URL example, store domain example, max_items up to 500, start_page). The description adds no parameter-level meaning beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb+resource: products belonging to a Shopify collection, and enumerates the return payload (options, variants, prices, availability). It is clearly distinct from run_shopify_collections (collections) and run_shopify_products (catalog-wide), though it never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites (e.g. needing a valid collection handle/URL), and no routing to alternatives such as run_shopify_products or run_shopify_products_search. The only decision-relevant hint is the implied cost line, which is not framed as usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Shopify product by store domain and handle: brand, type, tags, images, options and all variants with price, SKU, barcode, availability and stock. 5 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product handle or URL. e.g. mens-tree-runners | |
| store_domain | Yes | Store domain. e.g. gymshark.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose a real operational trait – '5 point per returned record' – which is valuable cost/pricing context. However, it omits auth requirements, error behavior for a missing/invalid handle, and whether the lookup is cached or rate-limited, leaving meaningful gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core operation and followed by the returned-field inventory and cost note. No filler; the field enumeration is dense but earned since there is no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates well by enumerating the returned fields (variants, pricing, SKU, barcode, availability, stock). The absence of usage routing and error semantics is the only real gap for a two-parameter lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters (product handle/URL, store domain) are fully documented in the schema, so a 3 baseline applies. The description restates 'by store domain and handle' but adds no format nuances beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: 'Get one Shopify product by store domain and handle', and it enumerates the returned shape (brand, type, tags, images, options, variants with price/SKU/barcode/availability/stock). The word 'one' implicitly separates it from search-style siblings like run_shopify_products_search, but it never names those siblings explicitly, so full sibling differentiation is not achieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites, no alternatives mentioned. An agent cannot tell from the description alone whether to use this single-product lookup or run_shopify_products_search / run_shopify_collections_products for a given query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all products of a Shopify store (not a keyword search) with variants, prices and availability. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page | |
| store_domain | Yes | Store domain. e.g. gymshark.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that records include variants, prices and availability, and adds a cost signal ('1 point per returned record'), which is genuinely helpful. It does not cover auth requirements, pagination behavior, or limits on the listing, leaving meaningful behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core purpose and scoping clause, then the cost note. Every element earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with no output schema, the description compensates by naming the returned fields and the billing model. Pagination semantics (how start_page interacts with max_items) remain unexplained, but overall the agent has enough to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (max_items, start_page, store_domain) are already documented, including the max of 500 and the store_domain example. The description adds no parameter-level meaning beyond the schema, which is the expected baseline here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('List all products of a Shopify store') and clarifies it is a full listing, not a keyword search, plus names returned content (variants, prices, availability). It does not explicitly distinguish itself from sibling run_shopify_products, but the purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical '(not a keyword search)' implies the correct usage context — enumerate a store's catalog rather than search by keyword — and the per-record point cost hints at the tradeoff when choosing it. However, no sibling alternative (e.g. run_shopify_products) is named as the alternative to use instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Slovenia registry (AJPES PRS) by registration number (matična številka) or registry link: name, short name, status (active/deleted), address, tax and VAT number, number of business units and the list of those units. 10 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Registration number (matična številka) or registry URL. e.g. 5043611000 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the returned fields and the cost ('10 point per returned record'), but omits read-only confirmation phrasing, not-found/error behavior, and any auth or rate-limit context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence front-loads the purpose and identifier, then lists outputs and cost. Efficient with little waste, though the field enumeration makes it long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by enumerating the returned fields (name, status, address, tax/VAT, business units), and covers the sole input. Only error/not-found behavior is left unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter already documents both the registration number and registry URL with an example. The description restates the matična številka and registry link forms but adds no new syntax or format guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get one company) and resource (Slovenia registry AJPES PRS) with the exact identifier type (matična številka or registry link) and enumerates returned fields. It clearly distinguishes itself from run_si_companies_search by specifying single-company retrieval by identifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The requirement of a registration number or registry link implies this is a lookup tool used once you already have an identifier, contrasted with the sibling run_si_companies_search for discovery. However, it never explicitly names the alternative or states a when-not condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Slovenia company registry (AJPES PRS) by company name: name, short name, registration number (matična številka), status (active/deleted), address, tax/VAT number and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Company name. e.g. krka | |
| max_items | No | Max items (up to 100) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It helpfully discloses the cost model ('1 point per returned record') and enumerates returned fields, but says nothing about rate limits, permissions, pagination depth, or result cap behavior. Cost disclosure is real added value, but the behavioral picture is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence covering registry, search key, and returned fields, followed by a short cost note. Front-loaded and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-param search tool with full schema coverage and no output schema, the description usefully enumerates the fields returned and the per-record cost, compensating for the missing output schema. Pagination params are covered by the schema, so the definition is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 keyword, status, max_items, and start_page. The description echoes the searchable field and status values but adds no syntax or format detail beyond the schema (and its 'active/deleted' wording slightly diverges from the enum's 'inactive/dissolved'). Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search) and resource (Slovenia company registry AJPES PRS), and names the search field (company name) plus the returned fields. Differentiation from the sibling run_si_companies (a likely direct lookup) is only implicit via 'by company name', so it falls just short of a clean 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrasing 'by company name' implies you invoke this when you have a name keyword, but there is no explicit when-to-use/when-not guidance and no named alternative (e.g. run_si_companies) to route against. Usage is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Slovakia Commercial Register (Obchodný register SR) by IČO or registry URL: name, status, registration date, address, legal form, activities and board, with full history. 10 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | IČO or registry URL. e.g. 31322832 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it does disclose meaningful behavioral facts — the 10-point cost per returned record and that 'full history' is included in the payload. It does not cover auth requirements, rate limits, or behavior when the IČO is not found, which matters for a paid single-record lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste: the identity/scope sentence is front-loaded, the returned fields are listed inline, and the cost note is a short trailing clause. Nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the field enumeration (name, status, registration date, address, legal form, activities, board, history) usefully substitutes for it, and the cost disclosure sets expectations. Only the failure-mode behavior (invalid IČO, company not found) is left unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'company' parameter, so the schema already documents IČO/URL input with an example. The description's 'by IČO or registry URL' merely restates the schema, adding no format or validation detail beyond it. Baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get), a single-resource scope (one company), names the source register (Obchodný register SR), and enumerates the returned fields. An agent can distinguish this from the plural sibling run_sk_companies_search without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'Get one company ... by IČO or registry URL', which tells the agent this is a lookup-by-identifier tool rather than a search tool. However, it never explicitly names run_sk_companies_search as the alternative when no identifier is known, nor mentions run_sk_company_filings for filing documents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Slovakia Commercial Register (Obchodný register SR) by the beginning of the business name: name and link to the registry extract. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Company name. e.g. slovnaft | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose useful behavior beyond the schema: prefix matching and a per-record cost ('1 point per returned record'), plus what is returned. However, it omits auth requirements, rate limits, pagination behavior, and error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that covers the register, the match rule, the return contents, and the cost with no filler. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description adequately conveys what the tool returns and how it matches. It stops short of describing pagination interaction between start_page/max_items, but for a simple search tool the essentials are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description meaningfully clarifies that keyword is a prefix ('beginning of the business name') match rather than an arbitrary substring — an operational detail the schema's 'Company name. e.g. slovnaft' does not convey. The other two params (max_items, start_page) are self-documenting in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (search the Slovakia Commercial Register) plus the matching scope (beginning of the business name) and output (name + link to registry extract). Clear and unambiguous, but it never names or contrasts with the sibling run_sk_companies, leaving an agent to infer the search-vs-detail distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the phrase 'by the beginning of the business name', which tells the agent how the query is matched. There is no explicit when-to-use/when-not guidance and no alternative tool (e.g. run_sk_companies) is offered for looking up a known company.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the documents in the Slovakia Commercial Register collection of documents (Zbierka listín) for one company, by IČO or registry URL: document name, type, delivery date and whether an electronic copy exists. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | IČO or registry URL. e.g. 31322832 | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds real value by naming the returned fields (document name, type, delivery date, electronic-copy flag) and the '1 point per returned record' cost signal, but says nothing about permissions, pagination behavior, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that moves from the core action and scope to the returned fields and cost. It is slightly dense with the enumerated fields, but every clause earns its place and nothing is repeated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with no output schema and no annotations, the description compensates reasonably by enumerating the returned fields and noting the per-record cost. It stops short of explaining pagination behavior across pages, which is the main residual gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces that `company` accepts an IČO or registry URL (matching the schema example), but adds no meaning for `max_items` or `start_page` beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and a precise resource — documents in the Slovakia Commercial Register collection (Zbierka listín) for a single company, keyed by IČO or registry URL — and enumerates the returned fields. This clearly separates it from sibling company tools like run_sk_companies and run_sk_companies_search, which deal with company listings rather than filings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for one company, by IČO or registry URL' implies the intended scope (look up filings for a known company), but there is no explicit when-to-use guidance, no mention of when to prefer run_sk_companies_search vs this tool, and no prerequisite/ordering notes. Usage is only inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List products of a Target category by browse node id or category URL with a sort order. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: featured = Featured, price_low = Price: low to high, price_high = Price: high to low, rating = Highest rated, bestselling = Best selling, newest = Newest | |
| category | Yes | Category (N-id or category URL). e.g. N-5xt3e | |
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose a genuine behavioral trait — the '1 point per returned record' cost model — which is real value beyond the schema. But it says nothing about read-only nature, pagination behavior beyond the schema's max_items, rate limits, or response shape, leaving a mutation/safety gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences: the primary operation and its inputs are front-loaded, and the cost note is appended without padding. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter listing tool with 100% schema coverage and no output schema, the definition covers the essentials but omits the return format and pagination semantics an agent would want when iterating pages up to 500 items. The absence of annotations also means the description should have carried more behavioral weight than it does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 four parameters including the sort enum values and the N-id/URL example. The description echoes category input and sort order without adding format, validation, or interaction details beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List), resource (products), and scope (of a Target category, by browse node id or category URL). This clearly separates it from generic product tools, though it never names the sibling it should be preferred over (e.g. run_target_products_search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage context via 'by browse node id or category URL', suggesting the caller must already have a category identifier. However, it gives no explicit when-to-use versus run_target_products, run_target_products_search, or the sibling *_categories_products tools from other retailers, and states no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Target product by TCIN or URL: price, ratings breakdown, images, specifications, features, variants, dimensions and return policy. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | TCIN or product URL. e.g. 86216189 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses the cost model ('Flat 5 points per successful run'), which also implies failed runs are not billed, and enumerates the returned data surface. It stops short of stating auth needs or error behavior for invalid TCINs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the identifier and scope are front-loaded, followed by the payload and cost. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, listing the returned fields (price, ratings, images, specs, features, variants, dimensions, return policy) is genuinely necessary and largely covers the gap. Authentication requirements and behavior on an unresolvable TCIN remain unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is a single parameter already documented as 'TCIN or product URL. e.g. 86216189'. The description's 'by TCIN or URL' merely restates that, adding no format or validation detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one Target product') plus the two accepted identifiers (TCIN or URL). The word 'one' implicitly contrasts with the sibling run_target_products_search, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Requiring a TCIN or URL implies the tool is a single-item lookup that typically follows a search, but the description never states when to use this versus run_target_products_search or what to do if you only have a product name. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Customer questions and their answers for a Target product by TCIN or URL. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | TCIN or product URL. e.g. 86216189 | |
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral context. It usefully discloses the cost model ('1 point per returned record'), but it does not describe return format, pagination behavior (beyond schema), or any rate limits. For a read-only retrieval tool this is adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core purpose and followed by a key cost note. No wasted words or redundant repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, full schema coverage, and absence of an output schema, the description provides sufficient context about what is returned (questions and answers) and the cost per record. A brief note on return structure would improve completeness, but nothing critical is missing for an agent to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 three parameters. The description only echoes the product identifier requirement ('by TCIN or URL') and adds no new semantic detail about max_items or start_page beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (customer questions and their answers) for a specific entity (Target product by TCIN or URL). This distinguishes it clearly from sibling tools like run_target_products_reviews or run_target_products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving Q&A content given a product identifier, but it does not explicitly state when to use this tool versus alternatives such as run_target_products_reviews or run_target_products_search. No exclusions or explicit comparison are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Related products Target shows on a product page: alternatives, guests also viewed, complementary, deals, top performing, new arrivals, similar. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Recommendation type. Options: alternatives = Alternatives, also_viewed = Guests also viewed, complementary = Complementary, deals = Deals, top_performing = Top performing, newness = New arrivals, similar = Similar | |
| product | Yes | Product (TCIN or URL). e.g. 86216189 | |
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose a genuine behavioral trait beyond the schema: '1 point per returned record', which is useful cost/capacity context for a paid scraper. However, it says nothing about read-only safety, pagination behavior, or auth requirements, leaving significant gaps for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the resource front-loaded and the cost note following. The category list slightly duplicates the enum, but it is the tool's core value and reads efficiently overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should carry more weight. It conveys what the tool returns and the point cost, but omits return shape, pagination semantics (start_page) and usage context, leaving it only minimally adequate for a 4-parameter scraper.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 four parameters including the enum mapping. The description's list of categories mirrors the enum options and adds no new meaning or syntax detail. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific resource and frame: 'Related products Target shows on a product page', which tells an agent exactly what data comes back. It enumerates the recommendation categories, further disambiguating it from sibling Target tools like run_target_products_reviews and run_target_products_search. It lacks an explicit action verb ('retrieve/list') but the intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no named alternative among the many sibling tools. It describes the return payload but leaves an agent to infer when recommendation data is preferable to, say, run_target_products or run_target_products_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Customer reviews of a Target product by TCIN or URL, newest first. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | TCIN or product URL. e.g. 86216189 | |
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds two genuinely useful behavioral facts beyond the schema: results are ordered newest-first and cost 1 credit per returned record. It stops short of describing what a review record contains, whether pagination is driven by start_page/max_items together, or any auth/rate-limit behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, and the most decision-relevant information (what it fetches, how to identify the product) is front-loaded before the cost/ordering note. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description is the only source of behavioral context. It covers ordering and cost but says nothing about the shape of a review record or how start_page interacts with max_items, leaving the agent to infer the return payload.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so 'product', 'max_items', and 'start_page' are already documented in the schema. The description restates the identifier format ('by TCIN or URL') and adds ordering, but nothing new about the two pagination parameters, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific resource (customer reviews), the target platform (Target), and the keying input (TCIN or URL), so an agent can immediately tell it apart from run_target_products and run_target_products_questions. It does not explicitly call out those siblings, but the resource noun 'reviews' is distinguishing enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool returns but never says when to choose it — no mention of prerequisites (e.g. needing a TCIN from run_target_products_search first) and no comparison to sibling tools like run_target_products_questions or run_walmart_product_reviews. Usage is only implied by the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search live Target products by keyword with a sort order (relevance, featured, price, rating, bestselling, newest). 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: relevance = Relevance, featured = Featured, price_low = Price: low to high, price_high = Price: high to low, rating = Highest rated, bestselling = Best selling, newest = Newest | |
| keyword | Yes | Search term. e.g. lego | |
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden, and it does add real behavioral context by disclosing 'live' data and a cost model ('1 point per returned record'). However, it omits return format, pagination behavior, and any auth or rate-limit context, leaving meaningful gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact clauses, front-loaded with the verb and resource. It is efficient and free of filler, though the parenthetical sort list is partly redundant with the schema enum.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter search tool with no output schema and no annotations, the description covers the core purpose and cost but says nothing about return shape or pagination semantics. Adequate but with clear gaps given the absence of structured safety/output metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents keyword, sort (with enum), max_items, and start_page. The description restates the sort values, which is redundant, and adds no syntax or interaction detail (e.g., how start_page and max_items combine). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (live Target products) plus the keyword mechanism, so an agent can identify it as the search variant of the Target toolset. It does not explicitly differentiate itself from siblings like run_target_products or run_target_categories_products, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, prerequisites, or named alternatives are given. The agent is left to infer that this is the keyword-search entry point versus the detail tools in the family (run_target_products, run_target_products_reviews).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from Tech.eu Funding Explorer by id or URL: description, location, sectors, every funding round with investors, exit and funding-signal estimates. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Company id (UUID) or Tech.eu URL. e.g. 14969163-8CB9-40A8-AFDB-2AA950E30E4F |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but does disclose meaningful behavior: the exact returned content and a billing trait ('Flat 5 points per successful run'). It omits error/not-found handling and permission requirements, keeping it short of full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that names the resource, the identifier format, the returned fields, and the cost. No filler sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description enumerates the principal returned fields, which is enough for an agent to know what it will get. The one-parameter schema is fully covered; only edge-case behavior (errors, missing companies) is undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
One parameter with 100% schema description coverage, so the schema already documents the 'company' field and its UUID/URL format. The description's 'by id or URL' merely echoes what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one company') plus the exact payload (description, location, sectors, funding rounds with investors, exit and funding-signal estimates). 'By id or URL' scopes it to a single-entity detail lookup and clearly distinguishes it from the techeu search siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by id or URL' implies this is a single-record detail lookup rather than a discovery tool, and no techeu companies-search sibling exists to route to. However, the description never explicitly states when to use this tool versus the techeu investors/rounds/exits siblings, so usage remains implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search European startup exits and M&A (Tech.eu Funding Explorer, CC BY 4.0), newest first: company, date, type, value in EUR and acquirer. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | To date (YYYY-MM-DD). e.g. 2026-01-01 | |
| from | No | From date (YYYY-MM-DD). e.g. 2026-01-01 | |
| country | No | Country (e.g. Germany, UK, France). e.g. Germany | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose real behavioral traits: sort order ('newest first'), the data source and its CC BY 4.0 license, and a per-record cost model ('1 point per returned record'). It omits any mention of pagination semantics (start_page) or rate/auth constraints, keeping it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence, front-loaded with the verb and resource, followed by output fields and the cost note. Every clause carries information, though the parenthetical license/source detail sits awkwardly mid-sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully enumerates returned fields, and the cost note compensates for absent annotations. The main gap is the unaddressed relationship between start_page and max_items for paginating a result set capped at 250.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 from, to, country, max_items and start_page. The description adds no syntax, format, or interaction guidance for those parameters, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Search') and a precise resource ('European startup exits and M&A'), names the underlying source, and enumerates the returned fields (company, date, type, value in EUR, acquirer). This clearly distinguishes it from sibling Tech.eu tools like run_techeu_rounds_search and run_techeu_companies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the resource description (use it for exit/M&A data), and the '1 point per returned record' clause gives a practical reason to bound results. However, it never states when to prefer this over run_techeu_rounds_search or run_techeu_investors_search, and gives no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one investor profile from Tech.eu Funding Explorer by name or URL: deals, portfolio, biggest deals, co-investors, sector / stage / country focus. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| investor | Yes | Investor name or Tech.eu URL. e.g. Sequoia Capital |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does add real value by disclosing the cost model ('Flat 5 points per successful run') and the single-profile scope, but says nothing about failure behavior, partial matches, or what a 'successful run' requires. Adequate but incomplete for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the operation and identifier before the data enumeration and cost. The list of returned fields is slightly dense but each item is informative rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup with no output schema and no annotations, the description covers purpose, accepted identifier, returned data categories, and cost. Only failure/ambiguity handling is absent, which is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
One parameter at 100% schema description coverage, so the schema already documents 'Investor name or Tech.eu URL'. The description's 'by name or URL' restates that without adding format, matching, or disambiguation detail. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Get one investor profile from Tech.eu Funding Explorer by name or URL', going on to enumerate the data returned (deals, portfolio, biggest deals, co-investors, focus). The 'one ... by name or URL' phrasing implicitly separates it from the run_techeu_investors_search sibling, though that sibling is never named explicitly, which keeps it short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'by name or URL' suggests this is the exact-lookup path when the investor identifier is already known, versus the search sibling. There is no explicit when-to-use statement, no guidance on ambiguous names or what to do if the name matches multiple investors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Tech.eu investor directory by name: type, number of deals and companies, top sector and active years. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: deals_desc = Most deals, companies_desc = Most companies, name = Name | |
| type | No | Type (e.g. Venture capital). e.g. Venture capital | |
| keyword | No | Investor name. e.g. sequoia | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden and does partly compensate by disclosing the per-record cost ('1 point per returned record') and the fields returned (deals, companies, sector, active years), which substitutes for the absent output schema. However it says nothing about pagination behavior, result limits, or any auth/rate-limit constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence plus a short cost clause; the purpose is front-loaded and there is no filler. Slightly dense because it mixes searchable criteria with returned fields, but efficiently sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter, no-annotation, no-output-schema tool the description does cover the returned field set, which is helpful. It still omits how to page through large result sets and when to prefer the sibling investor tools, so it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented in the schema (sort enum, type, keyword, max_items, start_page). The description only echoes 'by name' for keyword and adds nothing about the sort, paging, or type semantics, so the baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb (Search) and a specific resource (the Tech.eu investor directory) and lists the fields exposed (deals, companies, sector, active years). It does not distinguish itself from the sibling run_techeu_investors (the non-search lister) or from the many other *_investors_search tools, so sibling differentiation is missing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance and no mention of alternatives such as run_techeu_investors or run_eustartups_investors_search. 'By name' hints that keyword is the intended selector, but usage is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search European startup funding rounds (Tech.eu Funding Explorer, CC BY 4.0), newest first: company, amount in EUR, stage, investors, date and source. Filter by country, stage, sector, minimum amount and dates. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | To date (YYYY-MM-DD). e.g. 2026-01-01 | |
| from | No | From date (YYYY-MM-DD). e.g. 2026-01-01 | |
| stage | No | Stage. Options: Pre-Seed = Pre-Seed, Seed = Seed, Series A = Series A, Series B = Series B, Series C = Series C, Series D+ = Series D+, Early VC = Early VC, Growth/Late = Growth/Late, Debt = Debt, Grant = Grant, Crowdfunding = Crowdfunding, ICO = ICO, Other = Other | |
| sector | No | Sector. Options: Agritech = Agritech, AI = AI, Blockchain = Blockchain, Cleantech = Cleantech, Cloud = Cloud, Consumer = Consumer, Cybersecurity = Cybersecurity, Deeptech = Deeptech, Defence = Defence, E-commerce = E-commerce, Edtech = Edtech, Energy = Energy, Fashion = Fashion, Fintech = Fintech, Foodtech = Foodtech, Gaming = Gaming, Hardware = Hardware, Healthtech = Healthtech, HRtech = HRtech, Legaltech = Legaltech, Marketing = Marketing, Media = Media, Proptech = Proptech, Robotics = Robotics, Semiconductors = Semiconductors, Software = Software, Space = Space, Sports = Sports, Telecom = Telecom, Transportation = Transportation, Travel = Travel, Wellness & Beauty = Wellness & Beauty | |
| country | No | Country (e.g. Germany, UK, France). e.g. Germany | |
| max_items | No | Max items (up to 250) | |
| minAmount | No | Min amount (EUR) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses useful traits like ordering ('newest first'), point cost ('1 point per returned record'), and the CC BY 4.0 license, but omits whether the operation is read-only, how pagination works, or any rate limits—details that would matter without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it states the core purpose, returned fields, filter options, and cost in three efficient sentences. Every clause adds information, though the middle sentence listing filters is slightly dense and could be structured more cleanly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description helpfully enumerates the returned fields (company, amount in EUR, stage, investors, date, source) and the ordering ('newest first'). It also notes the credit cost. It lacks details on pagination behavior and error/empty-result handling, but given the fully documented input schema, it is substantially complete for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description summarizes the main filter dimensions but does not add syntactic or semantic detail beyond what the schema already provides (e.g., date format, enum ranges, pagination via start_page and max_items are left to the schema).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (Search) and resource (European startup funding rounds) and lists the returned fields, clearly distinguishing it from sibling tools like run_techeu_companies or run_techeu_exits_search. It also identifies the data source (Tech.eu Funding Explorer) and license, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it searches European startup funding rounds and lists filterable dimensions (country, stage, sector, minAmount, dates). However, it offers no explicit when-to-use guidance, no exclusions, and does not route the agent to or away from any of the many sibling tools that overlap in domain (e.g., run_techeu_companies, run_techeu_exits_search).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from There's An AI For That by slug or URL: description, industry, location, website, socials, AI-native flag, employees, valuation, ranks and its tools. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Company slug or There's An AI For That URL. e.g. openai |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose a cost model ('Flat 5 points per successful run'), which is genuinely useful context. However, it says nothing about permissions, failure behavior for an invalid slug, rate limits, or whether the call is idempotent. Partial disclosure for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence that names the action, the source, the key, and the payload, plus a short pricing sentence. Dense and free of filler, though the field enumeration is long enough to be slightly list-heavy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the field enumeration in the description usefully stands in for return-value documentation. What remains missing is how to obtain a valid slug, what happens on a miss, and any differentiation from sibling company-lookup tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'company' parameter, and the schema even gives an example ('openai'). The description repeats the slug-or-URL semantics without adding format, encoding, or normalization detail, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one company from There's An AI For That') and names the lookup key (slug or URL). It further enumerates the returned fields, so the agent knows exactly what it retrieves. It does not differentiate itself from the many other 'one company' siblings (e.g. run_techeu_companies, run_owler_companies), which keeps it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus run_search, run_extract, or run_theresanaiforthat_tools_search, and no note that the slug/URL typically comes from a prior search result. The agent is left to infer the lookup-by-identifier workflow entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AI ecosystem ranking of countries from There's An AI For That: region, AI market cap, population, AI investment per capita and the number of companies, organizations, investors, tools, models, papers, devices, robots and fundraises. Optional region filter. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | Region. Options: Central Asia = Central Asia, East Asia = East Asia, Europe = Europe, LATAM = LATAM, MENA = MENA, North America = North America, Oceania = Oceania, South Asia = South Asia, Southeast Asia = Southeast Asia, Sub-Saharan Africa = Sub-Saharan Africa |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds one genuinely useful behavioral fact — the flat 5-point credit cost per successful run — but says nothing about read-only safety, pagination, or result shape for a ranking endpoint. The cost disclosure is real added value but incomplete coverage keeps it at a middling score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and scope are front-loaded, followed by the cost note. The verbose field enumeration is long but earns its place since there is no output schema, and every clause is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description compensates by listing the returned fields and stating the cost. It is reasonably complete for a single-param, filterable ranking tool, missing only return format/pagination specifics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'area' parameter carries a full enum, so the schema does the work. The description's 'Optional region filter' merely restates the parameter without adding syntax or semantics beyond what the enum already conveys, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb+resource ('AI ecosystem ranking of countries from There's An AI For That') and enumerates the data fields returned (market cap, population, investment per capita, counts of companies/investors/tools/etc.). This clearly separates it from siblings like run_theresanaiforthat_tools or _companies, though it doesn't name those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage hint is 'Optional region filter,' which describes the parameter rather than when to reach for this tool over alternatives. There is no statement of when/when-not to use it or which sibling to prefer, leaving the routing entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one task (category) from There's An AI For That by slug or URL: number of tools, models, robots and devices, subscribers, most popular tool, subtasks, related tasks and the top tools. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Task slug or There's An AI For That URL. e.g. video-editing |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It adds value by listing the returned fields (tool counts, subscribers, subtasks, related tasks, top tools) and by disclosing a cost ('Flat 5 points per successful run'), but it says nothing about permissions, read-only nature, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the purpose before the return fields and cost. Efficient with little waste, though the roster of return fields is a slightly long run-on list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description bears the burden of explaining returns, and it does list the payload fields adequately. Combined with a single fully documented parameter, an agent has enough to call it correctly; only usage/routing context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already documents 'Task slug or There's An AI For That URL. e.g. video-editing'. The description merely restates 'by slug or URL', adding no format or syntax detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one task (category) from There's An AI For That by slug or URL') and enumerates the returned fields. The word 'category' clarifies the resource type, which helps distinguish it from sibling tools like run_theresanaiforthat_tools or run_theresanaiforthat_companies, though it never explicitly names those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no explicit naming of alternatives. The agent must infer from the resource noun ('task') that this tool is distinct from the tools/companies/countries siblings, which is weak routing guidance given the large family of near-identical names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one AI tool from There's An AI For That by slug or URL: tagline, description, website, pricing, rating and its breakdown, views, saves, task, company, country, features, releases, pros and cons, FAQ and counters of alternatives and reviews. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | Tool slug or There's An AI For That URL. e.g. gling |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose useful non-schema behavior: the complete set of returned fields and the exact cost model ('Flat 5 points per successful run'). It stops short of stating rate limits, failure behavior for an unknown slug, or any auth/credential requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both earning their place: the first front-loads the purpose and the returned-field inventory, the second carries the pricing note. The field enumeration is long but is doing the work of a missing output schema rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description compensates by enumerating the returned fields (tagline, pricing, rating breakdown, features, FAQ, counters, etc.), which is what an agent needs to judge whether the call answers its question. Only the routing guidance relative to the search/alternatives/reviews siblings is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter and schema description coverage is 100%, so the schema already explains that 'tool' accepts a slug or a There's An AI For That URL with an example. The description adds no syntax, normalization, or format detail beyond that, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one AI tool from There's An AI For That') and pins the identifier form ('by slug or URL'). The word 'one' plus the slug/URL lookup clearly separates it from the sibling run_theresanaiforthat_tools_search, which is the list/lookup counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: it is obvious you call this when you already have a slug or URL, and that search is for when you don't, but neither the prerequisite nor the alternative is stated. No exclusions or when-not-to-use guidance are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alternatives and similar tools of one There's An AI For That tool (top alternatives and "if you liked" recommendations): name, short description, task, price, rating, views and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | Tool slug or There's An AI For That URL. e.g. gling | |
| max_items | No | Max items (up to 250) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It helpfully discloses the returned fields (name, description, task, price, rating, views, link) and the cost model ('1 point per returned record'), which is genuine behavioral context. It omits anything about rate limits, auth, or the fact that this is a read-only lookup, so the 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that names the resource, lists the payload, and states the cost. Nothing wasted. The embedded title-case entity name makes it slightly awkward to read but not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by enumerating the returned fields, which is exactly what an agent needs to judge relevance. Combined with a fully documented 2-param schema, the definition is largely self-sufficient; only routing guidance versus sibling tools is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'tool' (slug or URL, with example 'gling') and 'max_items' (up to 250) documented in the schema. The description adds no meaning beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: returns alternatives and similar tools for a single There's An AI For That tool. It also enumerates the returned fields, so the agent knows what it gets. It stops short of naming sibling tools like run_theresanaiforthat_tools_search or run_theresanaiforthat_tools_reviews to sharpen the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the word 'alternatives'; there is no explicit when-to-use statement, no mention of prerequisites (you must already have a tool slug/URL), and no named alternatives. The sibling set is huge, so an explicit routing hint would have added real value.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reviews and comments of one There's An AI For That tool: text, star rating, date, release, votes and author. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | Tool slug or There's An AI For That URL. e.g. gling | |
| max_items | No | Max items (up to 250) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It usefully states the pricing model ('1 point per returned record'), which is genuine behavioral context, but omits read-only status, pagination/ordering behavior, and any auth or rate-limit notes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact clauses, front-loaded with the resource and followed by the returned fields and cost. No filler, though the field list and pricing could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, enumerating the returned fields (text, star rating, date, release, votes, author) usefully compensates. For a two-param read tool this is largely complete, with only usage routing and pagination behavior left unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both the 'tool' slug/URL and 'max_items' (up to 250) are documented in the schema. The description adds nothing beyond confirming a single tool is targeted, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource ('reviews and comments of one There's An AI For That tool') and enumerates the fields returned, so the agent knows exactly what it retrieves. The platform name and 'reviews' suffix distinguish it from the many other there'sanaiforthat tools, though it doesn't explicitly name a sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like run_theresanaiforthat_tools (metadata) or review tools on other platforms. The description is purely descriptive, leaving the agent to infer that this is the right call when reviews are wanted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search AI tools on There's An AI For That by keyword or task name: name, short description, task, price, rating, views, saves and link. Sorting and tool type apply to task names (for example seo or video editing). Paid placements are skipped. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort. Options: relevance = Relevance (site default), latest = Latest, top-rated = Top rated, most-saved = Most saved, popular = Popular, price = Price, sota = State of the art | |
| keyword | Yes | Keyword or task. e.g. video editing | |
| max_items | No | Max items (up to 250) | |
| tool_type | No | Tool type. Options: apis = APIs, agents = Agents, gpts = GPTs, ios = iOS, mini-tools = Mini tools, android = Android, chrome = Chrome, telegram = Telegram | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden and does disclose real behavioral facts beyond the schema: paid placements are skipped, results cost 1 point per returned record, and sort/tool_type only take effect when the query is a task name. It stops short of describing auth requirements or how start_page interacts with pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences, front-loaded with the core action, and no filler. The mid-sentence field list is a little cluttered but serves to tell the agent what comes back in the absence of an output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-output-schema search tool it covers the important ground: what is searched, what is returned, the cost per record, and the paid-placement exclusion. Remaining gaps are modest, mainly pagination/start_page behavior and result-set limits relative to max_items.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description earns above baseline by explaining an interaction the schema cannot express: sort and tool_type apply to task-name queries (e.g. 'seo', 'video editing'). That constraint meaningfully changes how an agent sets those parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (search AI tools on There's An AI For That) and enumerates the returned fields, which makes the tool's output concrete. It does not, however, distinguish itself from siblings such as run_theresanaiforthat_tools (browse) or run_futurepedia_tools_search, so the agent gets no routing help from the text alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'by keyword or task name', and the clause that sorting/tool type apply to task names hints at how to shape a query. But there is no explicit when-to-use vs. when-to-use-an-alternative guidance and no mention of the non-search siblings that overlap most closely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from Tracxn by profile URL or id token: description, website, founding year, location, stage, sectors, total funding, latest round, valuation, investors, revenue band, employee count, competitors, legal entities, board, the 3 latest funding rounds and news. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Company URL or id token. e.g. https://tracxn.com/d/companies/bigbasket/__lgBEzK2HajAJWbmAO0CnrQYnIPr1qailEUYRD4zGXVU |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose the returned payload fields and a cost signal ('Flat 5 points per successful run'), which is genuinely useful, but it says nothing about auth requirements, error/not-found behavior, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the verb and identifier, then the return contents, then the cost note. The long field enumeration is dense but informative; the only mild redundancy is restating the accepted input types already in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema available, enumerating the returned fields (funding, valuation, investors, competitors, news, etc.) is a real contribution and tells the agent what to expect. Combined with the pricing note, this is sufficient for correct invocation, though auth/error context is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'company' param already documents 'Company URL or id token' with an example. The description restates the same two input forms without adding format or validation detail, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one company from Tracxn') plus the accepted identifiers (profile URL or id token). The word 'one' cleanly separates it from the sibling run_tracxn_companies_search, and the field list makes the scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'one company' and 'by profile URL or id token' hint that you need a known identifier rather than a query, but no sibling is named and there are no stated exclusions or prerequisites. An agent must infer that this is the detail-lookup counterpart to the search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all funding rounds and the investor list of one Tracxn company (profile URL or id token): date, amount, round name, lead and other investors, plus the first-investment line of the institutional investors. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Company URL or id token. e.g. https://tracxn.com/d/companies/bigbasket/__lgBEzK2HajAJWbmAO0CnrQYnIPr1qailEUYRD4zGXVU |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose useful traits: the exact output content and a cost model ('Flat 5 points per successful run'), which is genuine value beyond structured fields. But it says nothing about authentication, rate limits, error behavior, or pagination for large funding histories.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: purpose and returned fields first, then the cost note. Front-loaded and free of filler, though the mid-sentence field enumeration is a bit dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description compensates well by enumerating the returned data (rounds, investors, first-investment line). It lacks any failure-mode or cost-vs-alternatives context, but is largely complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is only one parameter, whose schema description already gives a full example URL. The description's '(profile URL or id token)' merely restates the schema. Baseline 3 is appropriate since the schema does all the parameter work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get all funding rounds and the investor list of one Tracxn company', and enumerates the returned fields (date, amount, round name, lead/other investors). This is clearly distinct in scope from the generic run_tracxn_companies sibling. However, it never names a sibling to route the agent, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. The parenthetical '(profile URL or id token)' only hints at the input format, not the conditions that should select this tool over run_tracxn_companies or the investor/search siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the companies of a Tracxn list page (an explore list such as Auto Tech startups in India, or a sector /companies page): name, description, founded year, location, stage, total funding, investors, Tracxn score, competitor rank. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| explore | Yes | Tracxn list URL or id token. e.g. https://tracxn.com/d/explore/auto-tech-startups-in-india/__hVMq_SvfouSavYtGTT238hkb4bpf6AxJKMZXgXripxA | |
| max_items | No | Max items (up to 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose a real behavioral trait — a cost model of '1 point per returned record' — and explicitly lists what comes back. However, nothing is said about pagination (schema caps at 5 items), rate limits, or authentication, so the behavioral picture remains partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and scope, and the field list is informative rather than filler. It is one long sentence, and the field enumeration could be trimmed since much of it is return-value detail, but nothing is truly wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description compensates by explicitly naming the returned fields, and the input example clarifies the 'explore' parameter. Missing pieces are pagination behavior and why a sibling like run_tracxn_companies would be chosen instead, which keeps it short of a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters (explore URL/id token, max_items up to 5) are already documented in the schema, including an example URL. The description's example list adds marginal meaning but no syntax or format detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Get the companies of a Tracxn list page') and enumerates the returned fields (name, founded year, stage, funding, investors, score, rank). The 'list page / explore list' framing helps separate it from the single-company sibling run_tracxn_companies, but it never names that sibling, so sibling differentiation is only implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete example of the input domain ('Auto Tech startups in India, or a sector /companies page'), which implies when to use it, but offers no explicit when-not or pointer to run_tracxn_companies / run_tracxn_companies_funding for other needs. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one country startup landscape from Tracxn by URL or id token: totals, top companies and investors, recent funding rounds, acquisitions, IPOs and news. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| geography | Yes | Geography URL or id token. e.g. https://tracxn.com/d/geographies/india/__ujYf3QI9FSnpS3x-zJCSwnay2nENQhm1kAN-U8-6Kfg |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It usefully discloses the fixed credit cost ('Flat 5 points per successful run') and the data returned, but says nothing about auth requirements, rate limits, or failure behavior for an invalid URL/token.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the capability and its scope are front-loaded, and the cost note is short and additive. No filler, no restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with full schema coverage, the definition covers what is fetched and what it costs. The only gap is that there is no output schema and the description does not describe the shape or pagination of the returned landscape data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single geography parameter is already documented in the schema. The description adds only the mild clarification that the input may be either a URL or an id token, which the schema example already shows. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb and resource: 'Get one country startup landscape from Tracxn', and enumerates the payload (totals, top companies/investors, funding rounds, acquisitions, IPOs, news). This naturally separates it from the company-, investor-, and sector-level Tracxn siblings, but it never names an alternative to confirm the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives no when-to-use or when-not guidance and does not point to run_tracxn_companies, run_tracxn_investors, or run_tracxn_sectors as the alternatives for narrower scopes. With 200+ siblings, the absence of routing guidance leaves the agent to infer everything.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one investor (VC, PE, angel network, family office ...) from Tracxn by profile URL or id token: type, founding year, headquarters, portfolio and unicorn / IPO / acquisition counts, top investments, yearly / stage / sector / geography breakdowns, recent investments, team, co-investors and news. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| investor | Yes | Investor URL or id token. e.g. https://tracxn.com/d/venture-capital/bessemer-venture-partners/__OeR_ESlYvM5_W8zTJB8gzBaeS0kRaT7srV12ofBbql8 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It usefully discloses cost ('Flat 5 points per successful run') and enumerates the returned data (portfolio counts, breakdowns, co-investors, news), but says nothing about auth requirements, rate limits, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the purpose first, followed by the returned fields and pricing. It is dense but every clause conveys useful scope; the long field enumeration is the only thing bordering on bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description reasonably compensates by enumerating return fields (type, founding year, HQ, counts, breakdowns, team, co-investors, news). For a one-param lookup tool this is largely complete, though it omits auth and error/empty-result behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'investor' param is fully documented in the schema, including an example URL. The description adds meaning only by noting it accepts a profile URL or id token, which the schema already states, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one investor ... from Tracxn') and enumerates investor subtypes (VC, PE, angel network, family office). The provider name 'Tracxn' distinguishes it from sibling investor tools like run_pitchbook_investors and run_dealroom_investors, though it doesn't explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: you use this to fetch a single investor given a URL or id token. There is no explicit statement of when to prefer this over run_tracxn_investors_search-style tools or other provider investor lookups, and no prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one registered legal entity from Tracxn by URL or id token: CIN, status, type, incorporation date, registrar, capital, address, brands, business activity, recent filings, directors and signatories. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | Legal entity URL or id token. e.g. https://tracxn.com/d/legal-entities/india/supermarket-grocery-supplies-private-limited/__wkVBPMIeXFNcyh1StR0AqxcuG_kTfnVohmvVAUSR0jw |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it discloses two things structured data does not: the full set of returned attributes (CIN, status, registrar, capital, filings, directors, etc.) and the cost model ('Flat 5 points per successful run'). It does not cover failure behavior for an invalid token or any auth/rate-limit context, keeping it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, and the core action is front-loaded ahead of the field list and the cost note. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup with no output schema and no annotations, the description compensates well by enumerating the returned fields and stating the cost. Only error/edge behavior for malformed identifiers is left unspecified, which is minor for this tool shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the entity parameter already documents both the URL form and an example token. The description only restates 'URL or id token', adding no syntax or format detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one registered legal entity from Tracxn') and narrows the input mode ('by URL or id token'). The word 'one' and the identifier-based input implicitly separate it from the sibling search tool run_tracxn_legal_entities_search. The enumerated return fields further pin down exactly what the tool is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'by URL or id token' signals you call this when you already have an identifier rather than search criteria, which correctly distinguishes it from run_tracxn_legal_entities_search. But the description never names that alternative or states when not to use this tool, leaving the routing inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search 21.9M registered legal entities in Tracxn by name or CIN in one of 13 countries (default India): name, CIN, incorporation date, status, associated brands and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Name or CIN. e.g. supermarket grocery | |
| country | No | Country. Options: india = India, australia = Australia, croatia = Croatia, czech-republic = Czech Republic, denmark = Denmark, estonia = Estonia, germany = Germany, new-zealand = New Zealand, norway = Norway, poland = Poland, singapore = Singapore, thailand = Thailand, united-kingdom = United Kingdom | |
| max_items | No | Max items (up to 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does meaningful work: it discloses the corpus size (21.9M), the default country, the exact fields returned (name, CIN, incorporation date, status, associated brands, link), and the cost model (1 point per returned record). It does not mention auth requirements, error behavior, or rate limits beyond cost, which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence packs the corpus size, search keys, geography, returned fields, and cost with no filler. Every clause adds information an agent can act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema, the description adequately covers the search universe, input modes, default geography, returned fields, and cost. The main gap is that it does not clarify the relationship to its closest sibling run_tracxn_legal_entities, leaving an agent to guess which to call for a direct lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by stating the default country (India), which the enum does not indicate, and by restating the query's dual semantics (name or CIN). This is a modest but real addition over structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (21.9M registered legal entities in Tracxn), plus the two search keys (name or CIN) and geographic scope (13 countries, default India). It is clearly distinguishable from lookup-style siblings like run_tracxn_legal_entities, but it never names any sibling, so the differentiation is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the description of what can be searched. There is no statement of when to prefer this over run_tracxn_companies_search or the non-search run_tracxn_legal_entities, and no exclusions. The 'default India' hint helps, but routing guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one founder / angel investor / board member from Tracxn by profile URL or id token: roles, founded companies, board memberships, angel investments, portfolio exits and top news. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| person | Yes | Person URL or id token. e.g. https://tracxn.com/d/people/vipul-mahendra-parekh/__BNk8kxofnbLsm9sy__YeHmSG62ozKWP_3lDXQ9s_8IU |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does add useful context by enumerating what is returned (roles, founded companies, board memberships, angel investments, portfolio exits, top news) and by disclosing a flat cost of 5 points per successful run. It says nothing about auth requirements, rate limits, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the action and resource, followed by the returned data and cost. Every clause earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully enumerates the data categories returned, and it discloses the cost per run. It remains silent on error/failure behavior and on whether an id token must come from a prior Tracxn call, but for a single-param lookup tool it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'person' parameter already documents the URL-or-id-token format with an example. The description repeats the same URL/id token distinction without adding format or validation detail, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('Get one founder / angel investor / board member from Tracxn') plus the lookup key ('profile URL or id token'), which distinguishes it from the many sibling search tools like run_tracxn_companies_search. It stops short of naming which sibling to use for multi-person discovery, so it is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: 'one ... by profile URL or id token' signals a single-entity lookup, not a search, and 'per successful run' implies one profile per call. There is no explicit when-to-use/when-not or named alternative (e.g., a Tracxn people search) to route the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Tracxn sector overview by URL or id token: company / funding / unicorn / IPO / acquisition totals, top companies and investors, founding and funding trends by year and country, recent rounds, acquisitions, IPOs and news. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| sector | Yes | Sector URL or id token. e.g. https://tracxn.com/d/sectors/media-entertainment/__UjLT6RyYLO8O4V7vH3Q3ShdAwtHKGhed3BIqqt_Jm2A |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it does disclose a concrete behavioral trait — 'Flat 5 points per successful run' — which tells the agent the cost model and that failures aren't billed. However it omits auth requirements, error behavior for invalid tokens, and whether the data is a live or cached snapshot, leaving meaningful gaps for a scraping-style tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with verb, resource and input, then a dense content enumeration, then cost. Two sentences with no filler, though the long comma-separated content list is heavier than strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must convey return contents, and it does so thoroughly (totals, top companies/investors, trends, rounds, acquisitions, IPOs, news) and adds cost. Only auth/error behavior and snapshot freshness are absent, which are minor for a one-parameter lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and there is a single required parameter, so the schema already documents the sector argument with a concrete example URL. The description's 'by URL or id token' merely restates that accepted-format fact, adding no syntax or validation detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one Tracxn sector overview by URL or id token') and enumerates exactly what the result contains (totals, top companies/investors, trends, rounds, IPOs, news). The word 'sector' plus 'overview' cleanly separates it from company- and investor-level siblings like run_tracxn_companies and run_tracxn_investors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear you need a sector URL or id token and implies usage (sector-level aggregate view), but it never says when to prefer this over alternatives such as run_tracxn_companies_search or run_tracxn_geographies, nor any exclusions or prerequisites. Usage is inferable but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the unicorn startups of a country from Tracxn Unicorn Club (newest first): rank, name, description, founded year, location, stage, sectors, time to unicorn, top investors, employees, total funding, join date. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Country. e.g. India | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It adds real context beyond the name: the source table, newest-first ordering, the exact field set returned, and the cost model ("1 point per returned record"). It omits pagination behavior, whether max_items bounds billing, and any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence: verb + resource + source first, then the returned fields. The long field enumeration is dense but earns its place because no output schema exists. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the enumerated return fields are the only documentation of results, and the description supplies them, which is exactly what is needed. Gaps remain around pagination and billing interaction with max_items.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with country, max_items and start_page all documented including bounds, so the schema does the heavy lifting and a 3 baseline applies. The description contributes "newest first" ordering context relevant to start_page but nothing else parameter-specific.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ("List the unicorn startups of a country") and identifies the data source ("Tracxn Unicorn Club"), which cleanly separates it from generic siblings like run_tracxn_companies_search. It does not explicitly route against those siblings, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: an agent can infer you call this to enumerate unicorns for one country, and "newest first" hints at ordering intent. There is no explicit when-to-use, when-not-to-use, or named alternative among the many tracxn_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trendyol category tree: 10 departments with nested subcategories (id, name, alias, parent id, URL). Pass a category id or alias to get just that subtree. 5 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Category id or alias (optional). e.g. elektronik or 5 — leave empty for the full tree |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does reasonably well: it discloses the tree depth (10 departments), the nested structure, the returned field set, and an unusual cost trait ('5 point per returned record') that an agent cannot get from structured fields. It stops short of noting auth requirements or whether the full-tree call is expensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with what the tool returns before the invocation note. Every clause earns its place, including the billing note, and nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-parameter listing tool with no output schema, the description adequately covers both the return shape and the subtree-vs-full-tree behavior, so an agent can call it correctly. It leaves minor gaps on auth and pagination/cost scaling, but nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents the parameter, its optionality, examples (elektronik or 5), and the empty-value behavior. The description's 'pass a category id or alias to get just that subtree' restates the schema with a light behavioral framing but adds no new syntax or format detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource ('Trendyol category tree') and describes its shape: 10 departments with nested subcategories and the fields returned (id, name, alias, parent id, URL). The platform name plus 'categories' clearly separates it from sibling category tools like run_olx_categories or run_craigslist_categories, though it never states the action as an explicit verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to invoke it ('Pass a category id or alias to get just that subtree'), which is usage guidance for the parameter rather than for tool selection. It names no alternative and gives no when-not condition, so an agent must infer that this is the entry point for Trendyol category lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Trendyol product by contentId or URL: price, brand, rating, attributes, variants, seller and other sellers. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product ID or URL. e.g. 689227641 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the cost model ('Flat 5 points per successful run') and the return payload, but says nothing about auth requirements, rate limits, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the verb, resource, and accepted inputs, then the return contents and cost. Zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description compensates by listing the returned fields, plus input options and cost. It is nearly complete for a single-param lookup; only edge behavior (invalid ID handling) is unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the only parameter ('product') is documented as an ID or URL with an example. The description adds that the ID is a 'contentId', a minor semantic addition, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Get one Trendyol product') and enumerates the returned fields (price, brand, rating, attributes, variants, seller, other sellers). This is clearly distinct from a list tool, but it doesn't explicitly signal its boundary against siblings like run_trendyol_products_reviews or run_trendyol_products_sellers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by naming the two accepted inputs ('by contentId or URL') but gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The agent gets no signal on when to prefer this over the reviews or sellers siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Customer reviews for a Trendyol product by contentId or URL: rating, text, author, date, likes, seller and photos. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product ID or URL. e.g. 689227641 | |
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does useful work: it enumerates what each record contains (rating, text, author, date, likes, seller, photos) and discloses the pricing model ('1 point per returned record'). This cost and payload disclosure goes beyond what the schema provides, though pagination/rate-limit behavior is left implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose and resource, followed by payload and pricing details in a single efficient sentence. Little waste, though the phrasing is slightly dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only reviews tool with three fully documented parameters and no output schema, the description covers purpose, input form, returned fields, and credit cost. Pagination semantics are left to the schema but nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented in the schema. The description adds only a light hint about the 'product' input format ('contentId or URL') and nothing new for max_items or start_page, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (customer reviews for a Trendyol product) and lists the returned fields. It is clearly a reviews-fetcher, distinguishable from run_trendyol_products by the 'reviews' scope, though it never explicitly names that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says reviews can be fetched 'by contentId or URL', giving input-context guidance for the product parameter. However it offers no when-to-use/when-not guidance and does not route the agent to alternatives such as run_trendyol_products or run_trendyol_products_sellers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All sellers offering a Trendyol product by contentId or URL, for price comparison: price, score, stock, free shipping and which offer is featured. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product ID or URL. e.g. 689227641 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does disclose meaningful behavior: the returned comparison fields (price, score, stock, free shipping, featured offer) and the exact cost ('Flat 5 points per successful run'). It omits any auth, rate-limit, or pagination information, which for a zero-annotation tool leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences with no filler; the primary function is front-loaded before the return-field list and cost note. Slightly dense but every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter list tool with no output schema, the description covers what the tool does, what it returns, the accepted input forms, and the run cost. Nothing critical for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and only one parameter exists, so the baseline is 3. The description adds a small clarification by calling the identifier a 'contentId' versus the schema's generic 'Product ID', but contributes nothing beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: listing all sellers offering a given Trendyol product, retrievable by contentId or URL. The direction (product → sellers) is clear and distinguishable from the reverse sibling run_trendyol_sellers_products, though the description never names that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'for price comparison' implies the usage context, giving an agent a reason to pick this tool. However, no when-not conditions and no named alternatives (e.g. run_trendyol_products for the product itself, or run_trendyol_sellers_products for the inverse lookup) are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Trendyol seller (store) by id or store URL: name, city, score, product count, verified status and shipping/response metrics. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| seller | Yes | Seller ID or store URL. e.g. 992531 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does add one real trait: the 'Flat 5 points per successful run' cost disclosure. However it omits other behavioral context such as permission requirements, rate limits, or whether the lookup fails on a bad URL. 'Get' implies a read, but nothing else is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the resource and accepted inputs front-loaded, followed by the returned fields and the cost note. Nothing is redundant or padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description usefully enumerates the returned fields (name, city, score, product count, verified status, shipping/response metrics), which compensates for the missing output schema. It only falls short on usage routing among siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is a single parameter, so the baseline is 3. The description restates the accepted input ('id or store URL') but adds no syntax, format, or fallback detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one Trendyol seller (store) by id or store URL') and enumerates the returned fields, so the agent knows exactly what it retrieves. It does not name any sibling tool, so differentiation from run_trendyol_sellers_products or run_trendyol_products_sellers is left to inference, which keeps it out of 5 territory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use, when-not-to-use, or alternative-tool guidance is given. The agent must infer from the name alone that this returns a single seller rather than listing sellers or their products, which is a notable gap given the dense Trendyol sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A seller's storefront products on Trendyol by seller id or store URL: name, brand, price, rating, image. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| seller | Yes | Seller ID or store URL. e.g. 992531 | |
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose a real behavioral trait beyond the schema: '1 point per returned record', a cost signal that matters for deciding max_items. However, it says nothing about rate limits, pagination behavior (despite a start_page parameter), or whether results are capped.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the returned field list is packed in efficiently. It reads as an elliptical fragment rather than a complete sentence, which slightly hurts readability but not economy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, listing the returned fields (name, brand, price, rating, image) is genuinely useful, and the cost note helps sizing. Still missing for a 3-parameter paginated list tool: how start_page/max_items interact, whether pagination is bounded, and any indication of result caps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 seller, max_items, and start_page, making the baseline 3. The description restates the seller input ('seller id or store URL') but adds nothing about max_items limits or start_page behavior beyond what the schema says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (a seller's storefront products on Trendyol) and the two ways to identify the seller (id or store URL), which cleanly distinguishes it from the sibling run_trendyol_products_sellers that goes the opposite direction. An agent can pick this tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The input constraint ('by seller id or store URL') implies when the tool applies, but there is no explicit when-to-use statement, no exclusions, and no named alternative among the many Trendyol siblings (run_trendyol_sellers, run_trendyol_products, run_trendyol_products_sellers). Usage is inferable but not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full Trustpilot business profile by domain or URL: rating breakdown, claim status, and reply behavior. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| business | Yes | Business domain or Trustpilot URL. e.g. hubspot.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full disclosure burden. It does add useful non-schema context ('full profile', the cost of 'Flat 5 points per successful run', and that it works on domain or URL), but it omits read-only confirmation, failure behavior for unknown/unclaimed domains, and whether an exact domain match is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences: capability and payload first, cost second. Nothing redundant or padding; every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description adequately previews the return shape (rating breakdown, claim status, reply behavior) and discloses the credit cost. It falls short only on operational edge cases such as unknown domains or rate limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter, and schema description coverage is 100% — the schema already states 'Business domain or Trustpilot URL. e.g. hubspot.com'. The description repeats the same domain-or-URL semantics without adding format, normalization, or edge-case detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get full Trustpilot business profile') and enumerates the returned payload (rating breakdown, claim status, reply behavior). The 'by domain or URL' phrasing implicitly distinguishes it from run_trustpilot_search and run_trustpilot_reviews, but neither sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'by domain or URL' hints that this is a direct entity lookup rather than a keyword search, which is the relevant distinction from run_trustpilot_search. No explicit when-to-use, when-not-to-use, or prerequisite guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get customer reviews for a Trustpilot business by domain or URL: rating, text, and author. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| business | Yes | Business domain or Trustpilot URL. e.g. hubspot.com | |
| max_items | No | Max items (up to 300) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does disclose the key behavioral trait: '1 point per returned record', which tells the agent that cost scales with volume, a genuinely useful fact. It says nothing about pagination behavior, ordering, freshness, or what happens when max_items exceeds available reviews, which matters for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence covering purpose, input format, and returned fields, followed by a short cost note. The purpose is front-loaded; nothing is redundant or padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool with full schema coverage, the description compensates for the missing output schema by naming the returned fields and discloses the per-record cost. Only minor gaps remain, such as pagination or review-ordering behavior that the schema's max_items cap hints at but does not explain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (business, max_items) are already documented with examples and bounds. The description's 'by domain or URL' restates schema content, and 'rating, text, and author' describes outputs rather than parameters, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get customer reviews for a Trustpilot business') and names the returned fields (rating, text, author), so the agent knows this is the review-listing sibling rather than the business or search endpoint. It stops short of explicitly contrasting with run_trustpilot and run_trustpilot_search, which share the same provider.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an input format (domain or URL) but no guidance on when to choose this tool over the sibling run_trustpilot or run_trustpilot_search, nor any prerequisite or exclusion. The agent must infer the split from the tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Trustpilot businesses by keyword: name, domain, rating, and review count. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term. e.g. hubspot | |
| max_items | No | Max items (up to 300) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the cost model ('1 point per returned record'), which is genuinely useful behavioral context, but it omits permissions, pagination behavior, and result limits beyond the schema's max_items.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the resource and output fields front-loaded, followed by the cost note. No filler, though it is arguably under-specified rather than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter search with no output schema, the description covers the essentials but leaves the key ambiguity with run_trustpilot unresolved and does not explain return shape or result limits beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (query example, max_items range), so the schema does the heavy lifting. The description adds only which fields come back, not extra parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Search') and resource ('Trustpilot businesses') plus the fields returned (name, domain, rating, review count). However, it does not distinguish itself from the sibling tool run_trustpilot, leaving ambiguity about which Trustpilot entry point to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No indication of when to use this versus run_trustpilot or run_trustpilot_reviews. The agent is left to infer from the name alone that this is the keyword-search variant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the Taiwan registry (MOEA) by 統一編號 or registry link: name, status, registration date, address, company type, capital and shares, representative, business scope, directors, managers, branches, factories, warehouses, stock listing, trademarks and change history. 15 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | 統一編號 or registry URL. e.g. 22099131 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses the returned field set and a cost signal ('15 point per returned record'), which is real behavioral context, but says nothing about authentication, rate limits, or error behavior for an invalid identifier.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first clause, followed by the field enumeration and pricing. The long field list is justified because no output schema exists, and every item earns its place as return-value information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by enumerating the returned fields, and it documents the single input and its cost. For a single-record lookup this is largely complete, with only minor gaps around error/auth behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and there is a single parameter, so the schema already documents the 'company' input. The description's '統一編號 or registry link' merely restates what the schema description and example already convey, adding no new syntax or format detail. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one company from the Taiwan registry (MOEA)') and distinguishes itself from the search sibling via 'one company'. It doesn't explicitly name run_tw_companies_search as the alternative, so differentiation is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives input guidance ('by 統一編號 or registry link'), which implies you use this when you already have an identifier. However, it never states when to use this vs run_tw_companies_search for name/keyword discovery, leaving the choice to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Taiwan company registry (MOEA) by company name or 統一編號: name, registration number, status, address, registration authority and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Company name. e.g. 台灣積體電路 | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the cost model ('1 point per returned record'), which is real value, but says nothing about pagination (start_page/max_items exist), rate limits, or result ordering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that leads with the action and source, followed by a compact cost note. The colon-list of return fields is informative rather than wasteful, though slightly dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 100% schema coverage and no output schema, the description compensates well by enumerating the returned fields and noting the point cost. The only meaningful gap is pagination behavior, which the schema partially covers via start_page and max_items.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 four parameters (keyword, status, max_items, start_page). The description only echoes the lookup key ('company name or 統一編號') and adds no format or syntax detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search the Taiwan company registry (MOEA)') and names the two lookup keys (company name or 統一編號). It also enumerates the returned fields, making the search-scope clear. It does not explicitly differentiate from the sibling run_tw_companies detail tool, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it — when you have a company name or registration number — but gives no explicit when-not guidance and does not name an alternative tool (e.g. the full-record sibling). Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from the United Kingdom registry (Companies House) by registration number or registry URL: name, status, registration date, address and legal form. Flat 30 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Registration number or registry URL. e.g. 00445790 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses cost ('Flat 30 points per successful run') and the shape of the result, but says nothing about permissions, rate limits, or what happens when the registration number matches no company — meaningful gaps for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both earning their place: the first covers purpose, input, and output fields; the second covers cost. Front-loaded with the verb and resource, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by enumerating returned fields (name, status, registration date, address, legal form). It is nearly complete for a single-identifier lookup; only not-found/error behavior is left unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents the single 'company' parameter with an example ('00445790'). The description's mention of 'registration number or registry URL' merely restates the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one company from the United Kingdom registry') plus the identifier types accepted (registration number or registry URL). The word 'one' and the identifier requirement implicitly separate it from run_uk_companies_search and run_uk_company_filings, and the enumerated return fields tell the agent exactly what it will get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the precondition for use (you need a registration number or registry URL) but never names run_uk_companies_search as the alternative for name-based lookup, nor explains when to prefer this over run_uk_company_filings. Usage is implied by the required identifier rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the United Kingdom company registry (Companies House) by company name: name, registration number, status, address and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status. Options: active = Active, inactive = Inactive / dissolved | |
| keyword | Yes | Company name. e.g. tesco | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description must carry the full behavioral burden. It does usefully disclose the cost model ('1 point per returned record'), which is real behavioral value an agent cannot get from the schema. However, it says nothing about pagination behavior despite exposing start_page, nor about rate limits or auth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences with no filler: the registry, jurisdiction, search key, returned fields, and cost are all front-loaded. Nothing is redundant with the title or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by enumerating the returned fields (name, registration number, status, address, link), which is exactly what the agent needs to judge relevance. The remaining gap is the absence of any pagination note for start_page and no disambiguation from run_uk_companies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (keyword, status, max_items, start_page) are already documented with examples, ranges and an enum. The description only confirms the name-based search and does not add format or semantic detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and a precisely scoped resource (United Kingdom company registry / Companies House), plus the search key (company name) and the returned fields. This is enough to distinguish it from the many other country registries, though it never names the sibling run_uk_companies (full record) or run_uk_company_filings to draw the line explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by company name' implies the triggering condition, but there is no explicit when-to-use, when-not, or alternative-tool guidance. With ~200 siblings including run_uk_companies and run_uk_company_filings for the same jurisdiction, the agent gets no help choosing between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Filing history of one UK company (Companies House): date, type, description and document link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Registration number or registry URL. e.g. 00445790 | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the output shape (date, type, description, document link) and the cost model ('1 point per returned record'), but says nothing about permissions, rate limits, or error behavior when a company is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight clauses with zero filler; the resource and scope are front-loaded and the return fields plus cost follow immediately. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description's enumeration of return fields is valuable and largely sufficient for a simple fetch tool, with pagination covered by the schema. It falls short only on whether larger histories need paging through start_page and on error cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (company, max_items, start_page) are already documented, including the registration-number example and the 250 item cap. The description adds no parameter-level detail beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (filing history of one UK company), the data source (Companies House), and enumerates the returned fields (date, type, description, document link). An agent can distinguish it from run_uk_companies (which lists companies) or run_uk_companies_search without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'of one UK company' implies a single-entity lookup, but there is no explicit when-to-use guidance, no exclusion conditions, and no mention of the sibling run_uk_companies_search or how to resolve a company when the registration number is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search live Vinted items by keyword on any Vinted market, with category, brand, size, condition, color, material and price filters. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| order | No | Order. Options: newest_first = Newest first, price_high_to_low = Price: high to low, price_low_to_high = Price: low to high | |
| domain | No | Domain. Options: vinted.de = vinted.de, vinted.fr = vinted.fr, vinted.es = vinted.es, vinted.it = vinted.it, vinted.nl = vinted.nl, vinted.pl = vinted.pl, vinted.co.uk = vinted.co.uk | |
| keyword | Yes | Search term. e.g. nike | |
| currency | No | Currency. e.g. EUR | |
| price_to | No | Max price | |
| size_ids | No | Size IDs. e.g. 207 | |
| brand_ids | No | Brand IDs. e.g. 53, 88 | |
| color_ids | No | Color IDs. e.g. 9 | |
| max_items | No | Max items (up to 500) | |
| price_from | No | Min price | |
| start_page | No | Starting page | |
| status_ids | No | Condition (status) IDs. e.g. 6 | |
| catalog_ids | No | Catalog (category) IDs. e.g. 1904 | |
| material_ids | No | Material IDs. e.g. 44 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does add two useful facts beyond structured data: results are 'live' and each returned record costs 1 point. However, it says nothing about pagination behavior, auth/permission needs, or what happens when max_items/start_page interact, which matters for a 14-parameter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, and the core purpose and scope are front-loaded before the filter enumeration and cost note. Every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 14-parameter search tool with no output schema and no annotations, the description covers the what and the cost but leaves gaps: no return-shape or pagination explanation and no hint on how to obtain the numeric filter IDs. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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, which sets the baseline at 3. The description adds only a thematic list of filter families (category, brand, size, condition, color, material, price) and does not explain the opaque numeric ID formats (brand_ids, catalog_ids, status_ids) that an agent must source elsewhere.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) plus resource (live Vinted items) and enumerates the filter dimensions, so the agent knows exactly what it retrieves. It is distinguishable from the Vinted siblings (run_vinted_users, run_vinted_users_items) by being keyword-driven, but it never explicitly contrasts itself with them, keeping it short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no statement of when this is preferable to run_vinted_users_items or the other marketplace item-search tools, and no prerequisites or exclusions. The agent must infer the use case entirely from 'Search live Vinted items by keyword'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Vinted member profile by user id or member URL: location, reputation, feedback and item counts, followers, verification and bundle discounts. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| user | Yes | User ID or profile URL. e.g. 103792107 or https://www.vinted.de/member/103792107-katieronja | |
| domain | No | Domain. Options: vinted.de = vinted.de, vinted.fr = vinted.fr, vinted.es = vinted.es, vinted.it = vinted.it, vinted.nl = vinted.nl, vinted.pl = vinted.pl, vinted.co.uk = vinted.co.uk |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses only one trait: a flat 5-point cost per successful run. It says nothing about rate limits, required auth, error behavior, or whether the profile lookup is cached, leaving meaningful gaps for an unannotated read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and return contents, followed by the cost note. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description usefully enumerates the profile fields returned and the accepted identifier format, which is enough for an agent to call it correctly. The omission is that it never addresses the multi-domain parameter or any error/not-found behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented in the schema. The description reinforces that 'user' accepts an ID or URL, matching the schema, but adds no new semantics and never explains the 'domain' enum's role in selecting the Vinted storefront.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get a Vinted member profile') plus the identifier forms accepted, and enumerates the returned data (location, reputation, feedback/item counts, followers, verification, bundle discounts). It clearly scopes to the profile itself, though it never explicitly names the sibling sub-resource tools (run_vinted_users_items, run_vinted_users_feedbacks) to draw the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, prerequisites, or alternatives. The field listing implies the profile-retrieval use case, but nothing tells the agent how this differs from run_vinted_users_items or run_vinted_users_feedbacks, which are the closest siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Feedback (reviews) a Vinted member has received: text, rating, reviewer, the seller's reply and date. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| user | Yes | User ID or profile URL. e.g. 103792107 or https://www.vinted.de/member/103792107-katieronja | |
| domain | No | Domain. Options: vinted.de = vinted.de, vinted.fr = vinted.fr, vinted.es = vinted.es, vinted.it = vinted.it, vinted.nl = vinted.nl, vinted.pl = vinted.pl, vinted.co.uk = vinted.co.uk | |
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It adds one genuinely useful non-schema fact — '1 point per returned record' (a credit/cost disclosure) — which helps an agent budget calls. However, it says nothing about read-only nature, auth requirements, pagination behavior across pages, or error handling, leaving notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact clauses with no filler, and the returned-field inventory is front-loaded. Slightly less efficient than a pure verb-first statement, but every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only endpoint with four fully documented parameters and no output schema, the description compensates by enumerating the returned review fields. Pagination semantics (start_page plus max_items interaction) are not explained, a minor remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: user, domain enum, max_items and start_page are each documented in the schema. The description adds no parameter syntax or format details beyond what the schema already provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource — feedback/reviews received by a Vinted member — and enumerates the returned fields (text, rating, reviewer, seller's reply, date). It is distinguishable from siblings like run_vinted_users_items and run_vinted_users. It lacks an explicit verb (get/list) but the noun phrasing conveys the operation well enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is given, no prerequisites, and no mention of alternative tools (e.g. run_vinted_products_search or other review-fetching siblings). The agent must infer that this is the review-retrieval endpoint from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A Vinted member's current wardrobe: title-level data, prices, brand, size, condition, photos, favourites and reserved/closed/hidden flags. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| user | Yes | User ID or profile URL. e.g. 103792107 or https://www.vinted.de/member/103792107-katieronja | |
| domain | No | Domain. Options: vinted.de = vinted.de, vinted.fr = vinted.fr, vinted.es = vinted.es, vinted.it = vinted.it, vinted.nl = vinted.nl, vinted.pl = vinted.pl, vinted.co.uk = vinted.co.uk | |
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the return-field set and the cost model ('1 point per returned record'), which is genuine behavioral value. But it omits read-only status, pagination semantics for start_page/max_items, and any rate-limit or auth context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with the resource description front-loaded and the cost note trailing. No wasted prose, though the field enumeration is dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with no output schema and no annotations, the description partially compensates by naming the returned fields. It still leaves pagination behavior, read-only nature, and sibling differentiation unaddressed, leaving gaps an agent would need to resolve.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented in the schema. The description adds no parameter-level detail beyond the field list of results, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: a Vinted member's current wardrobe (their listed items), and enumerates the fields returned. It does not, however, distinguish this from siblings like run_vinted_users, run_vinted_users_feedbacks, or run_vinted_products_search, so an agent must infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance, no exclusions, and no mention of the alternative tools. The agent can only infer usage from the description of the returned data; nothing routes it against the sibling Vinted tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full Walmart product details by item ID: brand, price, rating, and specifications. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| item | Yes | Item ID or URL. e.g. 15290971475 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It usefully discloses cost ('Flat 5 points per successful run'), which is a valuable behavioral trait beyond structured data, but it omits explicit read-only confirmation, error behavior, and any other operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The purpose and returned fields are front-loaded, followed by a concise cost note that earns its place by informing invocation budgeting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with no output schema or annotations, the description covers what is returned (brand, price, rating, specifications) and how to invoke it. It could be slightly richer on failure modes or return format, but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single 'item' parameter including that it accepts a URL. The description adds no further parameter meaning beyond reinforcing 'by item ID', so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get), resource (full Walmart product details), and the key input selector (by item ID). The phrase 'by item ID' distinguishes it from search-oriented siblings like run_walmart_product_search, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when you have an item ID, but never explicitly says when to choose this tool over run_walmart_product_search or run_walmart_product_reviews. No alternatives or exclusions are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get customer reviews for a Walmart product by item ID: rating, text, and author. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Item ID or URL. e.g. 15545702811 | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses the billing model ('1 point per returned record'), which is real behavioral context, but says nothing about pagination behavior, rate limits, or whether any authentication/scope is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero waste; the resource and returned fields are front-loaded and the cost note is a compact trailing clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description helpfully names the returned fields (rating, text, author) and the cost per record. It is nearly complete for a simple read tool, missing only pagination behavior, which the schema's start_page/max_items parameters partially cover.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 product, max_items (up to 250), and start_page. The description only restates that the lookup is by item ID and adds nothing about the pagination parameters, making the baseline 3 correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (get customer reviews for a Walmart product) and enumerates the returned fields (rating, text, author), so an agent can distinguish it from run_walmart_product or run_walmart_product_search. It does not name any sibling explicitly, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'by item ID' tells you the required input, but there is no statement of when to prefer this over run_walmart_product or run_amazon_product_reviews, nor any prerequisite or exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Walmart products by keyword: title, price, rating, and seller. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: price_low = Price: low to high, price_high = Price: high to low, best_seller = Best seller, new = New arrivals, rating_high = Highest rated | |
| keyword | Yes | Search term. e.g. wireless mouse | |
| max_items | No | Max items (up to 250) | |
| max_price | No | Max price | |
| min_price | No | Min price | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose a useful non-schema behavior: '1 point per returned record,' which tells the agent cost scales with result count. It does not disclose pagination behavior (start_page exists), rate limits, or result shape, leaving gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero filler, with the search purpose front-loaded before the cost note. Efficient, though slightly terse for a 6-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With full schema coverage and no output schema, the description need not restate parameters, but it could say more about result counts, paging, or return shape. The cost note is helpful but the definition remains thin for a search endpoint with paging and sorting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter (sort, keyword, max_items, max_price, min_price, start_page) is already documented in the schema with enums and ranges. The description adds no syntax or format detail beyond that baseline, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (Walmart products) scoped by keyword, and names the data surface (title, price, rating, seller). It is clearly a Walmart retail search, distinguishable from the dozens of sibling retailer searches by the retailer name. However, it does not explicitly contrast with close siblings like run_walmart_product or run_walmart_seller_products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the name and description: use it to find Walmart products by keyword. There is no explicit when-to-use, when-not-to-use, or pointer to alternative tools such as run_walmart_product for a single item or run_amazon_product_search for a different retailer. Minimum viable for a self-explanatory search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Walmart marketplace seller profile by seller ID: rating, location, and contact info. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| seller | Yes | Walmart storefront catalogSellerId (numeric, e.g. 102730552) or a storefront URL containing it. Not the 32-character sellerId hash from product pages and search results: that hash has no storefront page and cannot be converted. Read the id from run-walmart-product's machine.product.seller.storefront_url for any item this seller offers — items sold by Walmart itself (seller.type INTERNAL) have no storefront, so the field is null for those. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the output fields and the cost model ('Flat 5 points per successful run'), which is useful. However, it does not describe permissions, error behavior, or read-only nature beyond the implicit 'Get' verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no wasted words. The purpose is front-loaded, and the pricing note is concise and useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool, the description plus the rich schema parameter description cover the core invocation. However, the lack of sibling routing and usage context leaves a meaningful gap for agent tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema contains a very detailed seller parameter description. The tool description adds no parameter meaning beyond 'by seller ID,' so the baseline 3 applies when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Get) and resource (Walmart marketplace seller profile) and lists key fields returned (rating, location, contact info). It does not explicitly distinguish the tool from close siblings such as run_walmart_seller_products or run_walmart_product, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance. The phrase 'by seller ID' implies the input requirement but does not tell an agent when this tool should be chosen over alternatives like run_walmart_seller_products or run_walmart_product.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List products from a Walmart seller's storefront: title, price, rating, and availability. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| seller | Yes | Walmart storefront catalogSellerId (numeric, e.g. 102730552) or a storefront URL containing it. Not the 32-character sellerId hash from product pages and search results: that hash has no storefront page and cannot be converted. Read the id from run-walmart-product's machine.product.seller.storefront_url for any item this seller offers — items sold by Walmart itself (seller.type INTERNAL) have no storefront, so the field is null for those. | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does add non-schema value by disclosing the cost model ("1 point per returned record") and the returned fields, but it omits pagination behavior, whether results are ordered/truncated, and any auth or credit-balance requirement — gaps that matter for a paginated list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler: the purpose/scope comes first and the cost note second. Nothing is repeated from the schema and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a fully documented 3-parameter schema and no output schema, the definition is largely sufficient — the agent knows what it returns, what it costs, and where to get the required ID. The remaining shortfall is the absence of pagination/usage guidance, which an agent must infer from `start_page` and `max_items`.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the `seller` description is unusually thorough (catalogSellerId vs. the 32-char sellerId hash, where to read the ID, and the INTERNAL null case), so the baseline of 3 applies. The tool description itself adds no parameter-level detail beyond the schema, though it does clarify the shape of records returned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("List products from a Walmart seller's storefront") and enumerates the returned fields (title, price, rating, availability). This scoping is clearly distinct from run_walmart_product (single item), run_walmart_product_search (keyword search), and run_walmart_seller (seller profile), so an agent can select it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The main description gives no when-to-use or when-not-to-use guidance relative to the sibling Walmart tools. The real routing signal lives in the `seller` parameter description (use catalogSellerId from run-walmart-product's machine.product.seller.storefront_url, and note that INTERNAL/Walmart-sold items have no storefront), which is useful but is parameter-level rather than tool-level guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full Wayfair product details by SKU (or product URL): title, brand, price, list price, discount, rating with per-star breakdown, images, variants, verified status, availability and category. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | SKU or product URL. e.g. W114765796 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose a genuine non-obvious trait — the flat 5-point cost per successful run — and the exact field set returned, but it says nothing about failure behavior for an invalid SKU/URL, whether the call is read-only, or any rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the verb and lookup key, followed by the returned fields and the cost. The field enumeration is long but each item is informative rather than filler; no preamble or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so enumerating the return fields (title, brand, price, list price, discount, rating breakdown, images, variants, verified status, availability, category) is exactly the right compensation, and the cost note is a useful extra. Only the missing error/edge-case behavior keeps it short of complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With one parameter and 100% schema description coverage (the schema already says 'SKU or product URL. e.g. W114765796'), the schema does the heavy lifting. The description restates the accepted input forms but adds no format or validation detail beyond it, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Get full Wayfair product details') and pins the lookup key ('by SKU (or product URL)'), then enumerates the returned fields. It is clearly distinguishable from a search-style tool, but it never names its obvious sibling run_wayfair_products_search, so differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: an agent can infer this is the detail lookup for a known SKU, versus the search endpoint. There is no explicit when-to-use/when-not-to-use guidance and no alternative named, so it is only minimally viable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Wayfair products by keyword. Returns products with title, brand, price, list price, currency, discount, rating, review count and images. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Search term. e.g. velvet accent chair | |
| max_items | No | Max items (up to 300) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It adds useful context by enumerating returned fields and disclosing the cost model ('1 point per returned record'), but says nothing about auth requirements, rate limits, pagination depth, or result caps beyond the schema's max_items.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded sentences with no filler: purpose first, then return shape, then cost. Every sentence earns its place, though the return-field list is somewhat long for a definition without an output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a keyword-search tool with full parameter coverage and no annotations, the description covers purpose, return fields, and pricing. The notable gap is the absence of routing guidance versus the many sibling product-search tools, but the core invocation information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so keyword, max_items (up to 300) and start_page are already documented inline. The description adds no syntax or format detail beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) plus resource (Wayfair products) and the mechanism (by keyword), which cleanly separates it from the retrieval-oriented sibling run_wayfair_products. It does not explicitly name a sibling to route against, but the verb+scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'by keyword' and the search nature, but there is no explicit when-to-use guidance or exclusion relative to alternatives like run_wayfair_products or other marketplace search tools. The agent must infer the selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Wayfair brand (seller) by id or brand page URL: name, description, logo image, alias and the brand's collections. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| seller | Yes | Brand ID or brand page URL. e.g. 44308 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return contents and a pricing model (flat 5 points per successful run), which is genuinely useful. However it says nothing about auth needs, error/failure behavior, or rate limits for a read call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence delivers purpose, accepted input forms, and returned fields, followed by a brief cost note. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with full schema coverage and no output schema, the description covers input forms, return fields, and cost. It is nearly complete, missing only auth/failure context that annotations would normally supply.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already documents 'Brand ID or brand page URL. e.g. 44308'. The description restates both accepted forms but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get) and resource (Wayfair brand/seller), plus the exact fields returned (name, description, logo, alias, collections). An agent can distinguish it from run_wayfair_products and run_wayfair_products_search without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by accepting an id or brand page URL, but never says when to choose this over the sibling Wayfair product tools or when-not to use it. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one WeFunder company by slug or URL: tagline, location, total raised and investors, current round (valuation, minimum investment, closing date), highlights, team, featured investors, memos, perks, FAQ and the latest updates and questions. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Company slug or WeFunder URL. e.g. riserobotics |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does well: it discloses the rich read content returned (round details, team, memos, FAQ, updates) and adds a cost signal ('Flat 5 points per successful run'). It stops short of stating read-only behavior explicitly, error handling, or rate limits, keeping it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the verb and resource, then a dense enumeration of returned fields that substitutes for the absent output schema, closing with the point cost. Every clause earns its place; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, no-output-schema tool, the description compensates well by enumerating return content and noting cost. It omits only minor context such as read-only semantics and failure behavior, so it is close to complete but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% – the single 'company' parameter is already documented with format ('slug or WeFunder URL') and an example ('riserobotics'). The description's 'by slug or URL' merely restates the schema, so baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one WeFunder company by slug or URL') and scopes it to a single entity, which distinguishes it from the run_wefunder_companies_search sibling that finds many. An agent can tell immediately what it fetches without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'one ... by slug or URL' phrasing implies this is the single-entity lookup versus the search sibling, but it never states when to prefer this tool or that search must be used first to obtain a slug. Usage is inferred rather than prescribed, and no exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse WeFunder campaigns by status, instrument and industry / highlight tags: name, tagline, raise progress, investors, valuation terms, founder and link. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort. Options: trending = Trending | |
| status | No | Status. Options: fundraising = Fundraising, funded = Funded | |
| security | No | Instrument. Options: equity = Equity, safe = SAFE, revenue_share = Revenue share, debt = Debt (convertible note) | |
| max_items | No | Max items (up to 250) | |
| highlights | No | Highlights (comma-separated). e.g. venture_backed, repeat_founder | |
| industries | No | Industries (comma-separated). e.g. technology, b2b | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the burden. It does disclose the cost model ('1 point per returned record'), which is genuinely useful behavioral context. But it says nothing about pagination (start_page/max_items behavior), auth requirements, or rate limits, leaving meaningful gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that opens with the verb and resource, then lists filters and output fields with no filler. Slightly dense but every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description compensates by enumerating the returned fields (name, tagline, raise progress, investors, valuation terms, founder, link) and stating the cost. Given seven all-optional filter parameters, this is reasonably complete, though it omits paging behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the enum options and comma-separated formats are already fully documented. The description only restates the filter axes and adds no syntax or format detail beyond the schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (Browse) plus resource (WeFunder campaigns) and the filter dimensions (status, instrument, industry/highlight tags). It also enumerates the returned fields. However, it does not differentiate itself from the sibling run_wefunder_companies, which is presumably the non-filtered counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance. The presence of run_wefunder_companies as a sibling makes the absence of any routing statement a real gap - an agent cannot tell from the text which of the two to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one company from Wellfound by slug or URL: description, size, stage, total raised, funding rounds, founders, tags, locations and open jobs. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Company slug or Wellfound URL. e.g. stripe |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses cost ('Flat 5 points per successful run'), which is genuinely useful behavioral context, and the verb 'Get' signals a read. It does not state auth requirements, rate limits, or what happens on an invalid slug, so transparency 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the core action and return fields, followed by the cost note. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the enumerated field list is the primary signal of what comes back, and the cost line adds a practical detail. For a single-parameter read tool this is largely complete, though error/edge-case behavior is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter is fully documented with an example ('e.g. stripe'). The description's 'by slug or URL' merely reinforces the schema rather than adding new syntax or format detail, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one company from Wellfound') and enumerates the returned fields, which makes the tool's scope concrete. It does not, however, differentiate itself from close siblings like run_crunchbase_company or run_yc_companies beyond the source name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'by slug or URL' implies the input mode and thus when the tool is applicable, but there is no explicit when-to-use guidance or routing to alternatives such as run_wellfound_jobs_search or run_wellfound_locations. Usage is inferable but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Wellfound jobs by role and location: job title, pay, locations, description and the hiring company (size, stage, tags). 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| role | Yes | Role (slug). e.g. software-engineer | |
| location | Yes | Location (slug). e.g. san-francisco | |
| max_items | No | Max items (up to 250) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the pricing model ('1 point per returned record'), which is real added value, but says nothing about pagination behavior (start_page/max_items), rate limits, or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that packs the resource, query dimensions, returned fields, and cost note without waste. Well sized for a search tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description compensates by enumerating the returned fields (job title, pay, locations, description, company size/stage/tags), and the schema fully covers inputs. Only the pagination and cost-scaling mechanics are left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 four parameters including slug examples. The description restates role and location but adds no format or syntax detail beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search) and resource (Wellfound jobs) and enumerates what each record contains (title, pay, locations, company size/stage/tags). An agent can distinguish it from siblings like run_wellfound_companies and run_wellfound_locations, though it never names them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by role and location' implies when the tool applies and matches the two required params, but there is no explicit when-to-use/when-not guidance and no reference to alternative search tools or pagination strategy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The list of Wellfound job locations (US cities, US states, countries and other places) with the slug to use as the location in Wellfound jobs search. Optional type and name filters. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Type. Options: city = US city, state = US state, other = Other (countries, regions, non-US cities) | |
| keyword | No | Name contains. e.g. york |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose useful behavioral facts beyond the schema: that the output is a list of locations with slugs, and that pricing is 'flat 5 points per successful run'. However it omits auth requirements, rate limits, and pagination behavior for a listing endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact and front-loaded: the resource and its return value come first, filters second, pricing last. Every clause carries information; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter, zero-required lookup with no output schema or annotations, the description covers purpose, output shape (locations + slug), filters, and cost. It is nearly sufficient, with only return format/pagination detail missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the enum values already documented inline. The description only restates 'optional type and name filters', adding no syntax, matching, or default detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (Wellfound job locations: US cities, US states, countries, other places) and what it yields (the slug usable as a location in Wellfound jobs search). This clearly differentiates it from run_wellfound_jobs_search, which consumes the slug, and from run_wellfound_companies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'with the slug to use as the location in Wellfound jobs search' supplies clear usage context: this is the lookup step that feeds a location-filtered jobs search. There is no explicit when-not or named alternative, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Yahoo! Auctions Japan category tree, one level at a time: pass a parent category id (0 for the top-level categories) to get its direct sub-categories (id, Japanese name, URL, parent id). 5 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Parent category ID (optional) | |
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the burden. It usefully discloses the returned fields (id, Japanese name, URL, parent id) and a cost signal (5 points per returned record), which is real behavioral context. However it omits auth/permission needs, rate limits, and error behavior for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence with the traversal rule and the return shape front-loaded. No filler; every clause conveys actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by listing the returned fields, and it explains the parent-id/0 traversal mechanic for a 3-optional-param tool. Pagination semantics (how start_page interacts with the tree) are the only notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds genuine meaning the schema lacks: it defines 'category' as a parent id and specifies the special value 0 for top-level categories. max_items and start_page are left to the schema, which documents them adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (retrieve sub-categories) and resource (Yahoo! Auctions Japan category tree), with the exact traversal rule (one level at a time). The 'Yahoo! Auctions Japan' qualifier cleanly distinguishes it from the many other *_categories siblings (olx, rakuten, ebay, trendyol, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear operational context: pass a parent category id, use 0 for the top-level categories, and traverse one level at a time. It doesn't explicitly name an alternative tool or state when-not to use it, but the traversal guidance is strong enough that an agent knows how to start.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one live or completed Yahoo! Auctions Japan listing by auction id or URL: price, bids, condition, category, description, photos, shipping, payment methods, highest bidders and seller. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| item | Yes | Auction ID or URL. e.g. d1236130164 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it usefully enumerates the payload (price, bids, condition, category, shipping, bidders, seller) and discloses a cost model ('Flat 5 points per successful run'). It still omits error behavior for invalid/expired ids, auth requirements, and any rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the verb and resource, and the cost note follows at the end. The middle field enumeration is long but each item conveys actual return content rather than filler, so it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must convey return content, and it does so with a reasonable field list. For a one-parameter lookup this is close to complete, though it could mention what happens with an invalid or ended auction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single 'item' parameter (auction ID or URL, with example d1236130164) is already fully documented. The description restates 'id or URL' without adding format, validation, or edge-case detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (Get) plus a precisely scoped resource: one live or completed Yahoo! Auctions Japan listing retrieved by auction id or URL. The word 'one' implicitly separates it from the many sibling search endpoints, and the returned-field list makes the operation concrete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'by auction id or URL' implies this is a direct lookup when an identifier is already known, and 'live or completed' hints that sibling searches cover discovery. However, no sibling is named and no explicit when-not/alternative guidance is given, so the agent must infer the boundary with run_yahoo_auctions_items_search and run_yahoo_auctions_items_closed_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search completed Yahoo! Auctions Japan auctions by keyword and see the price each item actually sold for, with sold-price, condition, region, seller-type and sort filters. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: ended_recent = Recently ended, ended_oldest = Oldest ended, price_asc = Sold price: low to high, price_desc = Sold price: high to low, bids_desc = Most bids, bids_asc = Fewest bids, popular = Popular, featured = Featured | |
| region | No | Shipped from. Options: hokkaido = Hokkaido, aomori = Aomori, iwate = Iwate, miyagi = Miyagi, akita = Akita, yamagata = Yamagata, fukushima = Fukushima, ibaraki = Ibaraki, tochigi = Tochigi, gunma = Gunma, saitama = Saitama, chiba = Chiba, tokyo = Tokyo, kanagawa = Kanagawa, yamanashi = Yamanashi, nagano = Nagano, niigata = Niigata, toyama = Toyama, ishikawa = Ishikawa, fukui = Fukui, gifu = Gifu, shizuoka = Shizuoka, aichi = Aichi, mie = Mie, shiga = Shiga, kyoto = Kyoto, osaka = Osaka, hyogo = Hyogo, nara = Nara, wakayama = Wakayama, tottori = Tottori, shimane = Shimane, okayama = Okayama, hiroshima = Hiroshima, yamaguchi = Yamaguchi, tokushima = Tokushima, kagawa = Kagawa, ehime = Ehime, kochi = Kochi, fukuoka = Fukuoka, saga = Saga, nagasaki = Nagasaki, kumamoto = Kumamoto, oita = Oita, miyazaki = Miyazaki, kagoshima = Kagoshima, okinawa = Okinawa, overseas = Overseas | |
| keyword | Yes | Search term. e.g. rolex | |
| brand_id | No | Brand ID | |
| category | No | Category ID | |
| condition | No | Condition. Options: new = New, used = Used (any), like_new = Like new, no_visible_damage = No visible damage, slight_damage = Slight damage, damaged = Damaged, poor = Poor condition | |
| has_image | No | With photo only | |
| max_items | No | Max items (up to 500) | |
| price_max | No | Max sold price (JPY) | |
| price_min | No | Min sold price (JPY) | |
| start_page | No | Starting page | |
| seller_type | No | Seller type. Options: store = Store, individual = Individual | |
| free_shipping | No | Free shipping only | |
| keyword_exclude | No | Excluded words (space-separated). e.g. box case |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. It does add one genuinely useful behavioral fact absent from the schema — '1 point per returned record' (a billing/cost trait) — and clarifies that returned items include realized sold prices. It says nothing about pagination, rate limits, or auth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the core capability front-loaded and the cost note appended. Efficient, though the mid-sentence filter list is somewhat enumerative and could be trimmed since the schema already covers those filters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 14-parameter search tool with no output schema and no annotations, the description covers the essential purpose, the result content (sold prices), and the cost, but omits pagination behavior (start_page/max_items semantics) and the absence of an output schema means return shape is only loosely implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 14 parameters are already documented in the schema. The description only summarizes a subset of filter families (sold-price, condition, region, seller-type, sort) and adds no syntax, format, or unit detail beyond what is in the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource (search completed Yahoo! Auctions Japan auctions) and scopes it to sold items with actual final prices. The word 'completed' plus 'price each item actually sold for' cleanly separates it from the active-listings sibling run_yahoo_auctions_items_search without naming it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: search by keyword, optionally narrowing with sold-price, condition, region, seller-type and sort filters. However, there is no explicit when-to-use guidance, no statement of when-not to use it, and no pointer to the active-auction sibling, leaving the agent to infer the distinction from the word 'completed'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search live Yahoo! Auctions Japan listings by keyword and/or category with price, buy-it-now, condition, region, seller, listing-type, appraisal, shipping filters and sort. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: newest = Newest, ending_soonest = Ending soonest, ending_latest = Ending latest, price_asc = Price: low to high, price_desc = Price: high to low, buy_now_price_asc = Buy-it-now: low to high, buy_now_price_desc = Buy-it-now: high to low, bids_desc = Most bids, bids_asc = Fewest bids, popular = Popular, featured = Featured | |
| region | No | Shipped from. Options: hokkaido = Hokkaido, aomori = Aomori, iwate = Iwate, miyagi = Miyagi, akita = Akita, yamagata = Yamagata, fukushima = Fukushima, ibaraki = Ibaraki, tochigi = Tochigi, gunma = Gunma, saitama = Saitama, chiba = Chiba, tokyo = Tokyo, kanagawa = Kanagawa, yamanashi = Yamanashi, nagano = Nagano, niigata = Niigata, toyama = Toyama, ishikawa = Ishikawa, fukui = Fukui, gifu = Gifu, shizuoka = Shizuoka, aichi = Aichi, mie = Mie, shiga = Shiga, kyoto = Kyoto, osaka = Osaka, hyogo = Hyogo, nara = Nara, wakayama = Wakayama, tottori = Tottori, shimane = Shimane, okayama = Okayama, hiroshima = Hiroshima, yamaguchi = Yamaguchi, tokushima = Tokushima, kagawa = Kagawa, ehime = Ehime, kochi = Kochi, fukuoka = Fukuoka, saga = Saga, nagasaki = Nagasaki, kumamoto = Kumamoto, oita = Oita, miyazaki = Miyazaki, kagoshima = Kagoshima, okinawa = Okinawa, overseas = Overseas | |
| keyword | No | Search term (optional when a category is set). e.g. rolex | |
| brand_id | No | Brand ID | |
| category | No | Category ID | |
| condition | No | Condition. Options: new = New, used = Used (any), like_new = Like new, no_visible_damage = No visible damage, slight_damage = Slight damage, damaged = Damaged, poor = Poor condition | |
| has_image | No | With photo only | |
| max_items | No | Max items (up to 500) | |
| price_max | No | Max current price (JPY) | |
| price_min | No | Min current price (JPY) | |
| start_page | No | Starting page | |
| marketplace | No | Marketplace. Options: yahoo_auctions = Yahoo! Auctions, yahoo_flea = Yahoo! Flea Market | |
| new_arrival | No | Newly listed only | |
| seller_type | No | Seller type. Options: store = Store, individual = Individual | |
| listing_type | No | Listing type. Options: auction = Bidding auctions, fixed_price = Fixed price | |
| authenticated | No | Authenticity appraisal only | |
| free_shipping | No | Free shipping only | |
| konbini_pickup | No | Convenience-store pickup | |
| keyword_exclude | No | Excluded words (space-separated, needs a search term). e.g. box case | |
| buy_now_price_max | No | Max buy-it-now price (JPY) | |
| buy_now_price_min | No | Min buy-it-now price (JPY) | |
| anonymous_shipping | No | Anonymous shipping | |
| ending_within_hour | No | Ending within 1 hour |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses the credit cost ('1 point per returned record') and that listings are 'live', but says nothing about pagination, authentication, or what happens to results beyond the page.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences that front-load the core action and scope; the cost note is a second sentence that earns its place. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 23-parameter tool with no annotations and no output schema, the description covers the searchable dimensions and cost but omits return format, pagination behavior, and result limits (e.g. max_items cap). Adequate but leaving real gaps for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every one of the 23 parameters is already documented, including enums and ranges. The description's filter list (price, condition, region, seller, etc.) only mirrors the schema and adds no syntax or defaulting detail, so baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (live Yahoo! Auctions Japan listings) with a clear filter scope. The word 'live' implicitly separates it from the closed-search sibling, but no sibling is named explicitly, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus alternatives like run_yahoo_auctions_items_closed_search or run_yahoo_auctions_items. The 'keyword and/or category' phrasing hints at a minimum input but offers no exclusions or routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Yahoo! Auctions Japan catalog product by id or URL: lowest current and buy-it-now price and the live auctions matched to that product. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Catalog product ID or URL. e.g. a9f58050a0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it does disclose two meaningful traits beyond the schema: the billing model ('Flat 5 points per successful run') and the returned content (lowest current and buy-it-now price plus matched live auctions). It stops short of mentioning auth requirements, rate limits, or pagination, which keeps it out of 5 territory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence front-loads the operation and resource, appends the return payload, and ends with the cost note — every clause earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with no annotations and no output schema, the description usefully covers what is returned and the pricing implication, which is most of what an agent needs. Auth, throttling, and error behavior are absent, but those are secondary for a simple lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is only one parameter, so the schema already documents 'product' as an ID or URL with an example. The description merely echoes that ('by id or URL') without adding syntax, format constraints, or lookup behavior beyond the schema, matching the baseline for full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — a Yahoo! Auctions Japan catalog product retrieved by ID or URL — and even names what is returned (lowest current and buy-it-now price plus matched live auctions). It is clear on its own, but with nearby siblings like run_yahoo_auctions_items and run_yahoo_auctions_items_search it never explicitly distinguishes the catalog-product lookup from those.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the accepted input (catalog product ID or URL) tells the agent this is a direct-lookup tool, not a search. It does not say when to prefer it over run_yahoo_auctions_items_search or other Yahoo Auctions siblings, and no prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Yahoo! Auctions Japan seller profile by seller id or URL: display name, rating count, positive-feedback percentage, store/verification badges and profile message. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| seller | Yes | Seller ID or URL. e.g. 8bdaxRiVapnRAmjjt2iWjM9wQzLXU |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the cost model ('Flat 5 points per successful run') and the returned profile fields, which is genuine behavioral value, but it omits permission/auth requirements, rate limits, and error behavior for an invalid seller.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste: the resource and return fields come first, the cost note last. Every clause carries information the agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully enumerates the returned fields and the cost, which is enough for a one-parameter read lookup. It falls short only on failure modes and whether the seller argument accepts any URL form or a constrained pattern.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter already documents 'Seller ID or URL' with an example. The description's 'by seller id or URL' adds no syntax, format, or validation detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get), a specific resource (Yahoo! Auctions Japan seller profile), and the two acceptable identifier forms. The enumerated return fields — display name, rating count, positive-feedback percentage, badges, profile message — clearly separate it from siblings like run_yahoo_auctions_sellers_items and run_yahoo_auctions_sellers_reviews.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (look up a seller by ID or URL) but never states when to prefer this over the sibling seller tools (items, reviews, reviews_summary) or what happens if the seller is not found. Usage is inferable from the resource name rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A seller's live Yahoo! Auctions Japan listings by seller id or URL, with keyword, category, price, condition, region and sort filters. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: newest = Newest, ending_soonest = Ending soonest, ending_latest = Ending latest, price_asc = Price: low to high, price_desc = Price: high to low, buy_now_price_asc = Buy-it-now: low to high, buy_now_price_desc = Buy-it-now: high to low, bids_desc = Most bids, bids_asc = Fewest bids, popular = Popular, featured = Featured | |
| region | No | Shipped from. Options: hokkaido = Hokkaido, aomori = Aomori, iwate = Iwate, miyagi = Miyagi, akita = Akita, yamagata = Yamagata, fukushima = Fukushima, ibaraki = Ibaraki, tochigi = Tochigi, gunma = Gunma, saitama = Saitama, chiba = Chiba, tokyo = Tokyo, kanagawa = Kanagawa, yamanashi = Yamanashi, nagano = Nagano, niigata = Niigata, toyama = Toyama, ishikawa = Ishikawa, fukui = Fukui, gifu = Gifu, shizuoka = Shizuoka, aichi = Aichi, mie = Mie, shiga = Shiga, kyoto = Kyoto, osaka = Osaka, hyogo = Hyogo, nara = Nara, wakayama = Wakayama, tottori = Tottori, shimane = Shimane, okayama = Okayama, hiroshima = Hiroshima, yamaguchi = Yamaguchi, tokushima = Tokushima, kagawa = Kagawa, ehime = Ehime, kochi = Kochi, fukuoka = Fukuoka, saga = Saga, nagasaki = Nagasaki, kumamoto = Kumamoto, oita = Oita, miyazaki = Miyazaki, kagoshima = Kagoshima, okinawa = Okinawa, overseas = Overseas | |
| seller | Yes | Seller ID or seller page URL. e.g. 8bdaxRiVapnRAmjjt2iWjM9wQzLXU (the token in /seller/{id}) | |
| keyword | No | Search within the seller's listings. e.g. Keyword | |
| brand_id | No | Brand ID | |
| category | No | Category ID | |
| condition | No | Condition. Options: new = New, used = Used (any), like_new = Like new, no_visible_damage = No visible damage, slight_damage = Slight damage, damaged = Damaged, poor = Poor condition | |
| has_image | No | With photo only | |
| max_items | No | Max items (up to 500) | |
| price_max | No | Max price (JPY) | |
| price_min | No | Min price (JPY) | |
| start_page | No | Starting page | |
| free_shipping | No | Free shipping only | |
| keyword_exclude | No | Excluded words (needs a keyword). e.g. box case |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It usefully discloses that listings are 'live' (distinguishing from the closed-auction sibling) and adds cost transparency ('1 point per returned record') — genuinely valuable context beyond the schema. However, it omits pagination behavior, auth requirements, and rate limits for a 14-param scraping tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste; the core scope is front-loaded ahead of the filter enumeration and the cost note. Efficient and readable, though slightly denser than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 14-parameter tool with no output schema and no annotations, the description is adequate but thin. The schema covers inputs fully, but the description does not describe the return shape or item structure, leaving the agent to infer output beyond 'listings' and the per-record cost.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 including enums for sort, region, and condition. The description only names a subset (keyword, category, price, condition, region, sort) without adding syntax, format, or defaulting details beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource (a seller's live Yahoo! Auctions Japan listings) and clarifies the scope is seller-scoped with optional filters. This distinguishes it from sibling tools like run_yahoo_auctions_sellers (seller info) and run_yahoo_auctions_items_search (site-wide search), though it doesn't name those alternatives explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the resource scope: use it to get a given seller's listings. There is no explicit when-to-use/when-not guidance, no mention of when to prefer run_yahoo_auctions_sellers or competitor tools like run_ebay_seller_items, and no prerequisites stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Feedback comments left for a Yahoo! Auctions Japan seller: verdict, author, auction, comment text and relative date; filter by role and verdict. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Role. Options: as_seller = Received while selling, as_buyer = Received while buying | |
| rating | No | Verdict. Options: positive = Positive, neutral = Neutral, negative = Negative | |
| seller | Yes | Seller ID or seller page URL. e.g. 8bdaxRiVapnRAmjjt2iWjM9wQzLXU (the token in /seller/{id}) | |
| max_items | No | Max items (up to 500) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the return shape (verdict, author, auction, comment text, relative date) plus a cost model ('1 point per returned record'). That cost disclosure is genuinely useful context beyond structured fields. It still omits pagination/auth behavior and rate limits, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence packs the resource, the returned fields, the filtering capability, and the cost model with no filler. It is slightly list-heavy but every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only extraction tool with no annotations and no output schema, the description names the returned fields and the per-record cost, which is enough for an agent to call it correctly. Pagination behavior is left implicit, but the schema exposes start_page and max_items.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, including enum explanations for role and rating, so the baseline is 3. The description's 'filter by role and verdict' merely echoes parameters the schema already documents fully, adding no syntax or format detail beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource — 'Feedback comments left for a Yahoo! Auctions Japan seller' — and enumerates the returned fields (verdict, author, auction, comment text, relative date). It does not explicitly differentiate itself from the sibling run_yahoo_auctions_sellers_reviews_summary, so the boundary between 'reviews' and 'reviews_summary' is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'filter by role and verdict' implies how to narrow results but is really a parameter restatement rather than when-to-use guidance. There is no explicit statement of when to call this versus run_yahoo_auctions_sellers_reviews_summary or the seller/item siblings, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregated Yahoo! Auctions Japan feedback score of a seller: total and positive percentage as seller/buyer plus positive/neutral/negative counts over the last week, month, 6 months, 100 and 1000 transactions. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| seller | Yes | Seller ID or URL. e.g. 8bdaxRiVapnRAmjjt2iWjM9wQzLXU |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and provides strong behavioral context by detailing the exact output (total and positive percentage, counts over specific periods) and credit cost. It does not explicitly state read-only status or error behavior, but for a retrieval tool this is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then adds a concise note about credit cost. Two sentences with no wasted words, though the long first sentence could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description adequately explains return values and pricing. It is nearly complete, lacking only explicit usage guidance and operational details like read-only status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single 'seller' parameter. The description adds no additional meaning or constraints beyond what the schema provides, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (Yahoo! Auctions Japan seller feedback) and the aggregated metrics returned, differentiating itself from detailed review tools by emphasizing 'aggregated' and 'summary'. It does not explicitly name sibling alternatives, so it falls short of a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as run_yahoo_auctions_sellers_reviews or run_yahoo_auctions_sellers. Usage is only implied by the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Yandex Market products in a catalog category by id or URL, with sort, price, condition, payment, rating and brand filters. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: dpop = Popularity, aprice = Price: low to high, dprice = Price: high to low, rating = Rating, date = Newest, discount_p = Biggest discount | |
| payment | No | Payment method. Options: online = Online, card_courier = Card to courier, cash_courier = Cash to courier, postpaid_pickup = Pay at pickup point | |
| category | Yes | Category (ID or URL). e.g. 26992150 | |
| condition | No | Condition. Options: new = New, resale = Resale / used | |
| max_items | No | Max items (up to 250) | |
| price_max | No | Max price (RUB) | |
| price_min | No | Min price (RUB) | |
| vendor_id | No | Brand (vendor ID) | |
| start_page | No | Starting page | |
| high_rating | No | Highly rated only |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the cost model ('1 point per returned record'), which is genuine behavioral context not available elsewhere. However, it omits pagination behavior, auth/credit prerequisites beyond cost, and any statement of what a call returns, leaving gaps for a 10-param listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the scope and supported filters come first, the cost note second. Nothing is wasted, though the filter enumeration slightly overlaps with schema content rather than adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description does give the one key return fact (points per record). For a 10-parameter, no-annotation listing tool, though, it should say more about pagination, result volume limits, and how it differs from the sibling products-search tools. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter including the three enums is fully documented in the schema. The description's filter list (sort, price, condition, payment, rating, brand) merely names what the schema already explains, adding no syntax or semantics beyond it. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (Yandex Market products) with scoping ('in a catalog category by id or URL'), which is clear and actionable. It does not, however, explicitly contrast itself with close siblings like run_yandexmarket_products or run_yandexmarket_products_search, leaving the boundary to be inferred from the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in a catalog category by id or URL' implies the tool is for category-scoped browsing, which is useful context. But there is no explicit when-to-use or when-not-to-use guidance relative to run_yandexmarket_products_search or run_yandexmarket_products, so selection between siblings is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Yandex Market product by id or URL: title, brand, price, rating, category breadcrumbs, seller and spec table. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product ID or card URL. e.g. 6078663913 or https://market.yandex.ru/card/…/6078663913 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full behavioral burden, and it does add genuinely useful context beyond the schema: it discloses the flat cost of 5 points per successful run and enumerates exactly what a successful call returns. It does not describe behavior on invalid/failed IDs, but for a low-risk read lookup this is a solid disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: purpose and returned fields first, cost second. Every clause (verb, resource, scope, returned fields, cost) earns its place and the most decision-relevant information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description compensates by enumerating the returned fields (title, brand, price, rating, breadcrumbs, seller, spec table) and the credit cost. With a single fully-documented required parameter, the definition is nearly complete; only failure/error behavior is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'product' parameter already has a descriptive entry with concrete ID/URL examples. The description's 'by id or URL' merely restates the schema without adding format, syntax, or edge-case detail, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb (Get) and resource (Yandex Market product) with clear scope (one product, by id or URL), which implicitly separates it from the search sibling run_yandexmarket_products_search. It also enumerates the returned fields, which sharpens what the tool is for. It stops short of naming the alternative sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by id or URL' conveys how the tool is invoked, and 'one' implies it is a single-record lookup rather than a browse. However, there is no explicit when-to-use vs. when-to-use-search guidance, no prerequisite information, and no exclusions, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Yandex Market products by keyword with sort, price, condition, payment, rating, brand and seller filters. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by. Options: dpop = Popularity, aprice = Price: low to high, dprice = Price: high to low, rating = Rating, date = Newest, discount_p = Biggest discount | |
| text | Yes | Search term. e.g. iphone 15 | |
| payment | No | Payment method. Options: online = Online, card_courier = Card to courier, cash_courier = Cash to courier, postpaid_pickup = Pay at pickup point | |
| condition | No | Condition. Options: new = New, resale = Resale / used | |
| max_items | No | Max items (up to 250) | |
| price_max | No | Max price (RUB) | |
| price_min | No | Min price (RUB) | |
| vendor_id | No | Brand (vendor ID) | |
| start_page | No | Starting page | |
| business_id | No | Seller (business ID) | |
| high_rating | No | Highly rated only |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the billing model ('1 point per returned record'), which is a real behavioral trait beyond the schema. However, it omits return format, pagination behavior, and any auth/rate-limit context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences with zero waste; the core purpose and the filter scope are front-loaded, and the cost model follows. Nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter tool with no annotations and no output schema, the description is on the thin side: it never addresses return shape or pagination, which the absent output schema leaves unstated. The rich schema compensates for parameter meaning, keeping this at a minimum-viable level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 11 parameters (including the three enums) are fully documented in the schema itself. The description only restates the filter categories in prose and adds no syntax or format detail beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search Yandex Market products by keyword') and enumerates the filter dimensions, so an agent knows exactly what it retrieves. It does not explicitly name or differentiate itself from the siblings run_yandexmarket_products or run_yandexmarket_categories_products, leaving that distinction to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the other yandexmarket siblings such as run_yandexmarket_products or run_yandexmarket_categories_products. Usage is only implied by the filter list, and no exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Y Combinator company by slug or URL: one-liner, description, batch, status, website, team size, location, founders with bios, social links, news and Launch YC posts. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Company slug or Y Combinator URL. e.g. airbnb |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the pricing model ('Flat 5 points per successful run') and the shape of the returned record, which is genuinely useful context. However, it says nothing about authentication requirements, error/failure behavior (e.g., unknown slug), or rate limits, leaving meaningful behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both front-loaded and functional: the first defines inputs and outputs, the second states cost. The long comma-separated field list is justified because no output schema exists, though it makes the first sentence dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter, full schema coverage, and no output schema, the description compensates well by enumerating the returned fields (one-liner, description, batch, status, founders with bios, news, Launch YC posts) and the cost. Only the absence of discovery guidance and failure behavior keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter already documents 'Company slug or Y Combinator URL. e.g. airbnb'. The description only restates this ('by slug or URL'), adding no format, normalization, or fallback guidance. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('Get one Y Combinator company') plus the lookup keys ('by slug or URL'), which implicitly separates it from the singular-vs-list sibling run_yc_companies_search. It also enumerates the returned fields, making the tool's scope unambiguous. It stops short of naming the alternative tool, so it earns a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the agent can infer 'use this when you already have a slug or YC URL, otherwise search first.' There is no explicit when-to-use statement, no pointer to run_yc_companies_search for discovery, and no prerequisites or exclusions. Adequate but with clear gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Y Combinator directory by keyword and filters (batch, industry, region, hiring, top company, nonprofit, team size): name, one-liner, batch, status, industries, regions, team size and website. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Keyword (optional). e.g. ai | |
| batches | No | Batches (comma-separated). e.g. Winter 2024, Summer 2024 | |
| regions | No | Regions (comma-separated). e.g. Europe, India | |
| sort_by | No | Sort by. Options: relevance = Relevance, launch_date = Newest first | |
| is_hiring | No | Hiring | |
| max_items | No | Max items (up to 250) | |
| nonprofit | No | Nonprofit | |
| industries | No | Industries (comma-separated). e.g. Fintech, B2B | |
| start_page | No | Starting page | |
| top_company | No | Top companies | |
| team_size_max | No | Team size to | |
| team_size_min | No | Team size from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It adds one genuinely useful behavioral fact — '1 point per returned record' — which lets the agent reason about cost, but says nothing about pagination behavior despite start_page/max_items, nor about auth or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with no filler, and the cost note is appended efficiently. The colon-separated field list makes the back half slightly dense but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description helpfully enumerates the returned fields (name, one-liner, batch, status, industries, regions, team size, website) and discloses cost. The remaining gap is pagination semantics for start_page/max_items, which the description omits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every one of the 12 parameters is already documented with type, enum, and example. The description only restates the filter categories and adds no syntax or interaction detail (e.g., how batches/regions compose), which is the expected baseline when the schema does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (Y Combinator directory) plus the filter dimensions and the fields returned, so the agent knows exactly what it queries. It does not, however, distinguish itself from the sibling run_yc_companies, leaving the search-vs-list split to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by keyword and filters' implies when to reach for it (keyword/faceted discovery), and the cost note hints at batching behavior, but there is no explicit when-to-use-vs-alternative guidance against run_yc_companies or the founders search siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the public Y Combinator founders directory by name keyword and filters (batch, title, industry, top company): name, title, company, batches, industries and region. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Keyword (optional). e.g. chesky | |
| titles | No | Titles (comma-separated). e.g. CEO, CTO | |
| batches | No | Batches (comma-separated). e.g. Winter 2024, S23 | |
| max_items | No | Max items (up to 250) | |
| industries | No | Industries (comma-separated). e.g. Fintech, B2B | |
| start_page | No | Starting page | |
| top_company | No | Top companies |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose a genuine trait beyond the schema – the '1 point per returned record' cost model – which helps an agent budget calls. However, it says nothing about pagination behavior, result ordering, or what happens when filters are combined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with the search scope front-loaded ahead of the cost note. The enumerated field list partially duplicates what the schema already exposes, but it is short enough not to be wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a seven-parameter, no-annotation, no-output-schema tool, the description covers what is searchable and the cost model, which is a reasonable minimum. It stops short of describing return contents or pagination semantics (start_page/max_items interplay), leaving gaps an agent must guess at.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 seven parameters and the baseline is 3. The description adds no syntax or format guidance, and it actually introduces a 'region' filter that does not exist in the schema, which is mildly misleading rather than clarifying.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (public Y Combinator founders directory), plus the dimensions it can be filtered on. It is distinguishable from the many run_yc_companies_* siblings by naming 'founders' explicitly, though it never names a sibling to contrast with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the scoping ('public YC founders directory') and by the listed filters, but there is no explicit when-to-use statement and no routing away from alternatives such as run_yc_companies_search or run_linkedin_people_search, which could plausibly be confused with it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get products of a Zalando brand by brand alias or brand page URL: name, brand, price, list price, discount, currency, image, silhouette, gender, flags and sizes. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | Yes | Brand alias or brand page URL. e.g. nike-sportswear | |
| max_items | No | Max items (up to 300) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It usefully discloses the credit cost ("1 point per returned record"), but says nothing about pagination behavior across start_page/max_items, rate limits, or failure modes for invalid brand aliases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that names the resource, the accepted input forms, and the returned fields, with the cost note appended. No filler, though the long field enumeration is dense rather than structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so enumerating returned fields (name, brand, price, discount, sizes, etc.) genuinely compensates. The cost note covers pricing, but pagination semantics for start_page/max_items remain unexplained, leaving a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 three parameters. The description only restates the brand input (alias or URL) and adds no meaning beyond the schema, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Get products of a Zalando brand") and pins the input to a brand alias or brand page URL, which distinguishes it from the search/related siblings. It is clear, though it never names or contrasts the closest sibling (run_zalando_products_search) explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the input description (use it when you have a brand alias or brand page URL), but there is no explicit when-to-use guidance, no exclusions, and no pointer to run_zalando_products_search or run_zalando_products for other lookup modes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full Zalando product details by product URL: name, brand, colour, price, list price, discount, 30-day lowest price, images, description, category, stock, sizes with stock levels, attributes (material, care, details) and colour variants. Flat 5 points per successful run.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product page URL. e.g. https://www.zalando.de/nike-sportswear-court-borough-recraft-unisex-sneaker-low-white-ni116d0lr-a15.html |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It helpfully enumerates the returned data (including derived fields like '30-day lowest price' and 'discount') and discloses the credit cost ('Flat 5 points per successful run'), which is real behavioral value. It says nothing about auth requirements, failure modes, or rate limits, so it remains incomplete for a zero-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence naming the resource, followed by a compact label list of return fields and a short cost sentence. The field enumeration is long but every item earns its place as output disclosure, and there is no boilerplate filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the detailed field list is the agent's only preview of the return shape and it covers that well; the single input parameter is fully specified. What is missing is guidance on when to prefer this over the sibling search/related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter is fully documented in the schema (100% coverage) with a concrete example URL. The description only restates 'by product URL', adding no new syntax or constraint information, so the baseline of 3 for high schema coverage applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get full Zalando product details'), and the 'by product URL' phrasing implicitly separates it from the search/related siblings. It never names those siblings explicitly, so an agent still infers the boundary rather than being told it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use statement, no exclusions, and no reference to alternatives. The agent is left to infer that a single-URL lookup is preferred over run_zalando_products_search when a URL is already in hand, but nothing in the text says so.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Zalando products by keyword with optional brand, size, colour, price range and sort filters. Returns name, brand, colour, gender, price, list price, 30-day lowest price, discount, image and sponsored flag. 1 point per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Size. e.g. M, 42, XL | |
| sort | No | Sort by. Options: popularity = Popularity, activation_date = Newest, price_asc = Price: low to high, price_desc = Price: high to low, sale = Sale | |
| brand | No | Brand (Zalando slug). e.g. nike-sportswear | |
| color | No | Color (English). e.g. black | |
| keyword | Yes | Search term. e.g. sneaker | |
| max_items | No | Max items (up to 300) | |
| max_price | No | Max price (EUR) | |
| min_price | No | Min price (EUR) | |
| start_page | No | Starting page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the return fields and the cost model ('1 point per returned record'), which are important operational traits. It does not state that the tool is read-only, how pagination behaves, or any rate-limit context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both front-loaded and waste-free: first the purpose and filters, then the return payload and cost. Nothing redundant or vague.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly fills the gap by listing return fields. It also notes the per-record cost. It omits pagination behavior (start_page, max_items) and any read-only safety note, which would be helpful for a 9-parameter search tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 9 parameters thoroughly. The description repeats the filter categories (brand, size, colour, price range, sort) but adds no syntax or format detail beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Search Zalando products by keyword'. This is clear and distinguishes it from generic search tools. It does not, however, explicitly differentiate itself from siblings like run_zalando_products, run_zalando_products_related, or run_zalando_brands_products, so a full 5 is not warranted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage ('Search ... by keyword with optional ... filters') but gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance. An agent must infer that this is the keyword-search entry point versus the other Zalando tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.1get_session_statusrun_agentrun_alibaba_productrun_alibaba_product_searchrun_aliexpress_productrun_aliexpress_product_reviewsrun_aliexpress_product_searchrun_amazon_productrun_amazon_product_offersrun_amazon_product_searchrun_amazon_sellerrun_amazon_seller_productsrun_ar_companiesrun_ar_companies_searchrun_at_companiesrun_at_companies_searchrun_au_companiesrun_au_companies_searchrun_avito_categoriesrun_avito_itemsrun_avito_items_searchrun_avito_sellersrun_be_companiesrun_be_companies_searchrun_betalist_startupsrun_betalist_startups_latestrun_betalist_startups_searchrun_betalist_topics_startupsrun_bg_companiesrun_bg_companies_searchrun_bg_company_filingsrun_br_companiesrun_br_companies_searchrun_ca_companiesrun_ca_companies_searchrun_ca_company_filingsrun_capterra_categoriesrun_capterra_category_productsrun_capterra_productrun_capterra_products_reviewsrun_capterra_products_searchrun_co_companiesrun_co_companies_searchrun_craigslist_areasrun_craigslist_categoriesrun_craigslist_postingsrun_craigslist_postings_searchrun_craigslist_postings_sellerrun_crunchbase_company1 field changedInput schema / properties / url / descriptionRemoved value: -"Crunchbase organization URL, e.g. https://www.crunchbase.com/organization/openai"run_cy_companiesrun_cy_companies_searchrun_cy_company_filingsrun_cz_companiesrun_cz_companies_searchrun_cz_company_filingsrun_dealroom_companiesrun_dealroom_companies_searchrun_dealroom_investorsrun_dealroom_investors_searchrun_dk_companiesrun_dk_companies_searchrun_dk_company_filingsrun_ebay_categoryrun_ebay_itemrun_ebay_item_searchrun_ebay_productrun_ebay_product_reviewsrun_ebay_sellerrun_ebay_seller_feedbackrun_ebay_seller_itemsrun_ec_companiesrun_ec_companies_searchrun_ee_companiesrun_ee_companies_searchrun_ee_company_documentsrun_email_enrichment1 field changedInput schema / properties / email / descriptionRemoved value: -"Email address to enrich."run_email_finder3 fields changedInput schema / properties / domain / descriptionRemoved value: -"Company domain, e.g. openai.com"Input schema / properties / first_name / descriptionRemoved value: -"Person's first name."Input schema / properties / last_name / descriptionRemoved value: -"Person's last name."run_email_validation1 field changedInput schema / properties / email / descriptionRemoved value: -"Email address to validate."run_es_companiesrun_es_companies_searchrun_eustartups_directoryrun_eustartups_directory_categoriesrun_eustartups_directory_searchrun_eustartups_investorsrun_eustartups_investors_searchrun_extract4 fields changedInput schema / properties / instructions / descriptionRemoved value: -"Natural-language description of what to extract."Input schema / properties / settings / descriptionRemoved value: -"Extraction settings."Input schema / properties / settings / properties / extract_schema_json / descriptionRemoved value: -"JSON-encoded schema string for the extraction shape."Input schema / properties / url / descriptionRemoved value: -"URL of the page to load and extract data from."run_fi_companiesrun_fi_companies_searchrun_flipkart_productrun_flipkart_product_reviewsrun_flipkart_product_searchrun_flipkart_sellerrun_fr_companiesrun_fr_companies_searchrun_futurepedia_categoriesrun_futurepedia_toolsrun_futurepedia_tools_alternativesrun_futurepedia_tools_reviewsrun_futurepedia_tools_searchrun_gartner_categoriesrun_gartner_marketrun_gartner_market_productsrun_gartner_markets_searchrun_gartner_productrun_gartner_products_searchrun_gartner_vendorrun_ge_companiesrun_ge_companies_searchrun_gleif_companiesrun_gleif_companies_searchrun_hepsiburada_categoriesrun_hepsiburada_categories_productsrun_hepsiburada_merchantsrun_hepsiburada_merchants_productsrun_hepsiburada_productsrun_hepsiburada_products_reviewsrun_hepsiburada_products_searchrun_hepsiburada_products_sellersrun_hr_companiesrun_hr_companies_searchrun_hr_company_filingsrun_il_companiesrun_il_companies_searchrun_indiegogo_campaignsrun_indiegogo_campaigns_searchrun_indiehackers_ideas_searchrun_indiehackers_postsrun_indiehackers_posts_commentsrun_indiehackers_posts_searchrun_indiehackers_productsrun_indiehackers_products_searchrun_indiehackers_usersrun_kickstarter_projectsrun_kickstarter_projects_searchrun_kleinanzeigen_categoriesrun_kleinanzeigen_listingsrun_kleinanzeigen_listings_searchrun_kleinanzeigen_listings_similarrun_kleinanzeigen_sellersrun_kleinanzeigen_sellers_listingsrun_kr_companiesrun_kr_companies_searchrun_kr_company_filingsrun_leboncoin_categoriesrun_leboncoin_listingsrun_leboncoin_listings_similarrun_leboncoin_locations_searchrun_leboncoin_sellersrun_leboncoin_sellers_reviewsrun_leboncoin_sellers_searchrun_lei_lookup_companiesrun_lei_lookup_companies_searchrun_lei_lookup_company_relationshipsrun_linkedin_company_employee2 fields changedInput schema / properties / companies / descriptionRemoved value: -"LinkedIn company URLs or names to search employees of."Input schema / properties / searchQuery / descriptionRemoved value: -"Free-text search query."run_linkedin_company_search7 fields changedInput schema / properties / companySize / descriptionRemoved value: -"Company size buckets, e.g. ['51-200']."Input schema / properties / industryIds / descriptionRemoved value: -"Industry filters."Input schema / properties / locations / descriptionRemoved value: -"Location filters."Input schema / properties / maxItems / descriptionRemoved value: -"Maximum number of results to return."Input schema / properties / scraperMode / descriptionRemoved value: -"Scraper depth mode, e.g. 'short' or 'full'."Input schema / properties / searchQuery / descriptionRemoved value: -"Free-text company search query."Input schema / properties / startPage / descriptionRemoved value: -"Page offset to start from."run_linkedin_domain2 fields changedInput schema / properties / company_or_domain / descriptionRemoved value: -"Company name or domain, e.g. openai.com"Input schema / properties / full_name / descriptionRemoved value: -"Full name of the person to find."run_linkedin_email1 field changedInput schema / properties / username / descriptionPrevious value: -"Full LinkedIn profile URL, e.g. https://www.linkedin.com/in/john-doe/"New value: +"Full LinkedIn profile URL."run_linkedin_people_search4 fields changedInput schema / properties / maxResults / descriptionRemoved value: -"Maximum number of results to return."Input schema / properties / scraperMode / descriptionRemoved value: -"Scraper depth mode, e.g. 'short' or 'full'."Input schema / properties / searchQuery / descriptionRemoved value: -"Free-text people search query."Input schema / properties / startPage / descriptionRemoved value: -"Page offset to start from."run_lu_companiesrun_lu_companies_searchrun_lu_company_filingsrun_lv_companiesrun_lv_companies_searchrun_lv_company_filingsrun_mercari_itemsrun_mercari_items_searchrun_mx_companiesrun_mx_companies_searchrun_mx_company_publicationsrun_newegg_categories_productsrun_newegg_productsrun_newegg_products_offersrun_newegg_products_reviewsrun_newegg_products_searchrun_newegg_sellersrun_newegg_sellers_productsrun_nl_companiesrun_nl_companies_searchrun_no_companiesrun_no_companies_searchrun_no_company_filingsrun_nz_companiesrun_nz_companies_searchrun_nz_company_documentsrun_olx_categoriesrun_olx_categories_filtersrun_olx_offersrun_olx_offers_searchrun_olx_regionsrun_olx_usersrun_olx_users_offersrun_owler_companiesrun_owler_companies_competitorsrun_owler_companies_newsrun_owler_companies_searchrun_pa_companiesrun_pa_companies_searchrun_phone_enrichment1 field changedInput schema / properties / phone / descriptionRemoved value: -"Phone number in international format, e.g. +1234567890"run_phone_enrichment_us1 field changedInput schema / properties / phone / descriptionRemoved value: -"US phone number, e.g. 12069735100"run_pitchbook_companiesrun_pitchbook_investorsrun_pitchbook_profiles_searchrun_pitchwall_productsrun_pitchwall_products_searchrun_pl_companiesrun_pl_companies_searchrun_pl_company_filingsrun_poshmark_itemsrun_poshmark_items_commentsrun_poshmark_items_likesrun_poshmark_items_relatedrun_poshmark_items_searchrun_poshmark_usersrun_poshmark_users_followersrun_poshmark_users_followingrun_poshmark_users_itemsrun_poshmark_users_searchrun_producthunt_categoriesrun_producthunt_categories_listrun_producthunt_collectionsrun_producthunt_collections_searchrun_producthunt_forums_searchrun_producthunt_forums_threadsrun_producthunt_launchesrun_producthunt_launches_searchrun_producthunt_leaderboardsrun_producthunt_productsrun_producthunt_products_alternativesrun_producthunt_products_customersrun_producthunt_products_launchesrun_producthunt_products_reviewsrun_producthunt_products_searchrun_producthunt_topicsrun_producthunt_usersrun_producthunt_users_collectionsrun_producthunt_users_commentsrun_producthunt_users_launchesrun_producthunt_users_stacksrun_producthunt_users_upvotesrun_pt_companiesrun_pt_companies_searchrun_pt_company_filingsrun_rakuten_categoriesrun_rakuten_itemsrun_rakuten_items_reviewsrun_rakuten_items_searchrun_rakuten_shopsrun_rakuten_shops_itemsrun_researchrun_ro_companiesrun_ro_companies_searchrun_se_companiesrun_se_companies_searchrun_se_company_filingsrun_search2 fields changedInput schema / properties / query / descriptionRemoved value: -"Search query."Input schema / properties / settings / descriptionRemoved value: -"Search settings."run_seedrs_businessesrun_seedrs_campaignsrun_seedrs_campaigns_searchrun_shopify_collectionsrun_shopify_collections_productsrun_shopify_productsrun_shopify_products_searchrun_si_companiesrun_si_companies_searchrun_sk_companiesrun_sk_companies_searchrun_sk_company_filingsrun_target_categories_productsrun_target_productsrun_target_products_questionsrun_target_products_recommendationsrun_target_products_reviewsrun_target_products_searchrun_techeu_companiesrun_techeu_exits_searchrun_techeu_investorsrun_techeu_investors_searchrun_techeu_rounds_searchrun_theresanaiforthat_companiesrun_theresanaiforthat_countriesrun_theresanaiforthat_tasksrun_theresanaiforthat_toolsrun_theresanaiforthat_tools_alternativesrun_theresanaiforthat_tools_reviewsrun_theresanaiforthat_tools_searchrun_tracxn_companiesrun_tracxn_companies_fundingrun_tracxn_companies_searchrun_tracxn_geographiesrun_tracxn_investorsrun_tracxn_legal_entitiesrun_tracxn_legal_entities_searchrun_tracxn_peoplerun_tracxn_sectorsrun_tracxn_unicorns_searchrun_trendyol_categoriesrun_trendyol_productsrun_trendyol_products_reviewsrun_trendyol_products_sellersrun_trendyol_sellersrun_trendyol_sellers_productsrun_trustpilotrun_trustpilot_reviewsrun_trustpilot_searchrun_tw_companiesrun_tw_companies_searchrun_uk_companiesrun_uk_companies_searchrun_uk_company_filingsrun_vinted_products_searchrun_vinted_usersrun_vinted_users_feedbacksrun_vinted_users_itemsrun_walmart_productrun_walmart_product_reviewsrun_walmart_product_searchrun_walmart_sellerrun_walmart_seller_productsrun_wayfair_productsrun_wayfair_products_searchrun_wayfair_sellersrun_wefunder_companiesrun_wefunder_companies_searchrun_wellfound_companiesrun_wellfound_jobs_searchrun_wellfound_locationsrun_yahoo_auctions_categoriesrun_yahoo_auctions_itemsrun_yahoo_auctions_items_closed_searchrun_yahoo_auctions_items_searchrun_yahoo_auctions_productsrun_yahoo_auctions_sellersrun_yahoo_auctions_sellers_itemsrun_yahoo_auctions_sellers_reviewsrun_yahoo_auctions_sellers_reviews_summaryrun_yandexmarket_categories_productsrun_yandexmarket_productsrun_yandexmarket_products_searchrun_yc_companiesrun_yc_companies_searchrun_yc_founders_searchrun_zalando_brands_productsrun_zalando_productsrun_zalando_products_relatedrun_zalando_products_searchv1.0.0get_session_statusrun_agentrun_crunchbase_companyrun_email_enrichmentrun_email_finderrun_email_validationrun_extractrun_linkedin_company_employeerun_linkedin_company_searchrun_linkedin_domainrun_linkedin_emailrun_linkedin_people_searchrun_phone_enrichmentrun_phone_enrichment_usrun_researchrun_searchScored across 342 tools
Most tools are clearly distinguishable by source platform and entity/action, and descriptions help distinguish similar operations. Minor ambiguities exist, such as run_phone_enrichment vs run_phone_enrichment_us, run_trustpilot vs run_trustpilot_search, and the many country-specific company-registry tools.
The set overwhelmingly follows a consistent run_ + snake_case convention, often with source/entity/action suffixes. A few deviations appear, including singular vs plural forms and prefixes, such as run_trustpilot, run_ebay_item, run_poshmark_users_following vs run_poshmark_users_followers.
342 tools is far too many for a coherent MCP server surface. Even as an aggregator, this volume makes selection, maintenance, and discovery unwieldy and strongly exceeds reasonable bounds.
The surface covers an enormous breadth of verticals: web search/extract, contact enrichment, marketplaces, company registries, startup directories, review sites, and more. Gaps are minor and mostly reflect read-only limitations rather than missing core operations.
The OpenRouter for tools. One MCP connection gives any AI agent 254 hosted tools, pay per call.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
LinkedIn actions for AI agents: search, messaging, posts and invites, as hosted MCP tools.
214 tools for AI agents over one MCP endpoint: image, video, audio, 3D, data, storage, mail, GPUs.
