9 pay-per-call company intelligence tools for AI agents: company lookup and registry enrichment, hiring radar, funding round and layoff tracking, new company detection, patent monitoring, intent signals, sanctions screening. Free discovery + pricing_info; paid calls $0.01-0.02 in USDC on Base via x402 — pay only for successful runs.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.9/5 across 19 of 19 tools scored. Lowest: 2.9/5.
Several tools overlap in purpose: company-lookup and company-registry-enricher both return GLEIF registry data; lead-list-qualifier and intent-signal-aggregator both score buying intent; sanctions-screening is a subset of counterparty-risk-rollup. However, each tool has unique additional features (tech stack, UK directors, risk score, etc.) that help differentiate them.
Nearly all tool names follow a consistent hyphenated lowercase noun-phrase style (e.g., company-hiring-radar, funding-round-tracker, patent-monitor). The single deviation is pricing_info which uses an underscore, and there is no verb_noun pattern, but the overall convention is predictable and readable.
With 19 tools, the set is on the heavier side but still reasonable for a company intelligence bundle covering many distinct signal types (hiring, funding, sanctions, litigation, registry, patents, contacts). It is slightly over the ideal 3-15 range, but each tool serves a niche purpose without feeling gratuitously duplicated.
The tool surface covers a broad range of company intelligence signals and includes both one-time lookups and ongoing monitors. Minor gaps exist: there is no tool to manage saved watchlists/filters for the alert tools, and no general news or financial data beyond funding/layoffs, but these are workable for most use cases.
company-hiring-radarAInspectPull every open role a company is hiring for from its public job board (Greenhouse, Lever, Ashby) and turn it into a buying/expansion signal: role count, which functions are growing (sales, engineering, marketing), remote share and what's new. No login, no scraping, no proxies. — $0.01/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| keywords | No | Highlight roles whose title, department or function contains any of these words (e.g. `sales`, `marketing`, `growth`). Matched roles are returned separately in `matchedRoles`. | |
| companies | Yes | One entry per company. Best form is `provider:token` — e.g. `greenhouse:stripe`, `lever:spotify`, `ashby:ramp`. The token is the company's slug on its job board (the part in the careers URL). A bare token like `stripe` auto-detects the provider. | |
| newWindowDays | No | A role counts as new if it was first published within this many days. | |
| maxConcurrency | No | How many companies to check in parallel. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does add meaningful context: it discloses no login/scraping/proxies and pricing ($0.01/call with x402/USDC). However, it omits details like rate limits, error behavior, or output structure. It provides some transparency but not rich behavioral 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?
The description is a single, dense sentence that front-loads the main action ('Pull every open role...') and includes key selling points. The pricing note ('$0.01/call, x402') is slightly cryptic but still relevant for cost. No wasted words, though the 'x402' could confuse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 output dimensions (role count, functions growing, remote share, new roles) and mentions constraints. It does not describe the full response format or error handling, but it covers the core value proposition well for a moderately 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 the baseline is 3. The description reinforces the provider tokens by naming Greenhouse, Lever, and Ashby, but it does not add new semantics beyond what each parameter description already provides. It earns the baseline but not higher.
Input schemas describe structure but not intent. Descriptions should explain 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 it pulls every open role from a company's public job board (Greenhouse, Lever, Ashby) and converts it into a buying/expansion signal with specific outputs (role count, growing functions, remote share, new roles). It distinguishes from siblings by highlighting the ATS provider scope and the 'no login, no scraping, no proxies' angle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 use case ('turn it into a buying/expansion signal') and notes constraints ('No login, no scraping, no proxies'), but it does not explicitly state when to prefer this over sibling tools like hiring-trend-index or provide exclusions. Guidance is inferred rather than directly spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
company-lookupAInspectTurn a domain or company name into one unified company card: website tech stack (CMS, ecommerce, key tech) for domains, plus a live GLEIF registry match (legal name, jurisdiction, status, LEI). Keyless, no login — built for AI agents and sales. — $0.01/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| companies | Yes | Company domains (e.g. "stripe.com"), legal names (e.g. "Monzo Bank Limited") or LEIs to look up. One row per entry. Add a country hint after a pipe — "stripe.com | US" — to keep the registry match inside one country; same-named companies exist in several. An LEI is used as-is, with no name search. | |
| maxConcurrency | No | How many companies to look up in parallel. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds valuable context: 'Keyless, no login' and '$0.01/call, x402 (USDC on base)' as well as 'live GLEIF registry match' indicating freshness. However, it does not mention limitations like rate limits, error handling, or behavior for invalid inputs, leaving gaps in 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?
The description is compact and front-loaded with the core purpose, followed by pricing and target audience. The phrase 'built for AI agents and sales' is slightly redundant given the tool's nature, but overall it earns its place. It is a single well-structured sentence with minimal 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?
Given the lack of an output schema, the description adequately explains the return value: 'unified company card' with tech stack and GLEIF fields. It covers key aspects like input types and payment. However, it omits edge-case behavior (e.g., unresolved domains, multiple matches, rate limits), so it is 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%, with detailed parameter descriptions for 'companies' (including pipe-delimited country hints and LEI handling) and 'maxConcurrency' (min/default/max). The tool description adds some context (e.g., tech stack outputs) but does not materially enhance parameter understanding beyond the schema, falling to 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?
The description clearly states the tool's function: 'Turn a domain or company name into one unified company card' with specific outputs (website tech stack, GLEIF registry match). It distinguishes itself from siblings like company-registry-enricher by explicitly combining tech stack detection with registry enrichment, making its scope unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 provides clear context: it is 'built for AI agents and sales' and covers both domain tech stack and legal registry info. It implies when to use it (when needing a combined company card) but does not explicitly mention exclusions or alternative tools, 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.
company-registry-enricherAInspectTurn a company name, LEI or UK company number into an official registry card: legal name, status, jurisdiction, registered address and LEI via GLEIF (free, no key). Optionally add UK directors and SIC codes with your own Companies House API key. — $0.01/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| companies | Yes | Legal names, LEIs (20-char code) or UK company numbers to look up. One row per entry. A name can carry a country hint after a pipe — "Monzo Bank Limited | GB" — which is what separates same-named companies in different countries. An LEI or UK company number is used as-is, with no name search. | |
| maxConcurrency | No | How many companies to look up in parallel. | |
| companiesHouseApiKey | No | Your own free UK Companies House API key. When set, GB entities are enriched with directors and SIC codes. Get one at developer.company-information.service.gov.uk. Leave empty to get the GLEIF card only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. It does convey important behavioral details: cost ($0.01/call, x402 USDC on base), free GLEIF lookup without key, and optional Companies House key. However, it omits other behavioral aspects such as rate limits, idempotency, error handling, or output format, leaving gaps in 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?
The description is compact and information-dense, with three sentences that each earn their place: the core transformation, the optional extension, and the cost/payment method. It front-loads the primary purpose and avoids fluff, 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?
Given no output schema, the description compensates by listing expected return fields (legal name, status, jurisdiction, registered address, LEI) and optional enrichments. It covers cost, key requirement, and input types. However, it does not address edge cases like ambiguous names or error responses, which keeps it slightly below 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 description coverage is 100%, so each parameter is already well documented. The tool description adds minimal param-specific meaning—it mentions 'company name, LEI or UK company number' but that mirrors the schema's companies description. The optional key behavior is also already detailed in the schema. Thus, the description adds little 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 clearly states the tool's function with a specific action ('Turn a company name, LEI or UK company number into an official registry card') and lists concrete output fields (legal name, status, jurisdiction, registered address, LEI). It distinguishes from siblings by specifying data sources (GLEIF, Companies House), making it unmistakably focused on registry 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 description provides context for when to use the tool: when you need official registry data from GLEIF for free, and optionally Companies House data with an API key. It explains the optional key usage ('Optionally add UK directors and SIC codes with your own Companies House API key') but does not explicitly mention alternatives or exclusions, stopping short of a full when-not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
competitor-change-rollupBInspectOne card per competitor summarising what changed across several signals in the past week. Partial cards are marked partial and list which signals are missing. — $0.08/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The competitor's domain to watch, e.g. "stripe.com". | |
| baseline_key | No | A name for this watch, in case you want to run more than one watch on the same domain with different settings. Defaults to the domain itself. | |
| role_keywords | No | Highlight when this competitor is hiring for roles matching these words (passed to our company-hiring-radar Actor). | |
| company_name_override | No | By default this Actor guesses the company's ATS token / name from the domain itself (e.g. "stripe.com" -> "stripe") for the hiring and funding checks — this is a best-effort heuristic, not a verified identity, and CAN be wrong (see README). Set this if you know the real ATS token or legal name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It explains partial cards and missing signals, but does not state whether the operation is read-only, safe, or has side effects. The pricing note is extra but not behavioral.
Agents need to know what a tool does to the 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 very concise, using two sentences plus a pricing note. It delivers the core function without waste, though a slightly more structured format could improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 four parameters, the description adequately explains the output format (card per competitor, partial cards), but lacks details on return type, pagination, or data freshness. It covers essentials but has 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 parameters well. The description adds no additional parameter semantics beyond the schema, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain 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 tool produces a summary card per competitor covering changes across multiple signals over the past week. It distinguishes itself from sibling tools (like company-hiring-radar or funding-alert) by being an aggregate rollup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 lacks explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it or suggest alternatives, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
counterparty-risk-rollupAInspectScreen a counterparty in one call: OFAC + EU sanctions match, GLEIF legal-entity registry, litigation history (US/UK/PL) and a hiring signal from public ATS boards, combined into one row per company with a documented risk score. Keyless sources only. — $0.03/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| checks | No | Which of the four checks to run per company. Sanctions and registry are fast (shared cached list + one API call); litigation and hiring each add one more API call per company. | |
| companies | Yes | Company legal names to assess, one per row (a Legal Entity Identifier is also accepted for the registry check). One dataset row comes out per company, combining every check you selected below. | |
| maxConcurrency | No | How many companies to assess in parallel. | |
| jurisdictionHint | No | Optional ISO country code, e.g. "GB", "DE", "PL". Narrows the registry lookup to that country and picks which litigation source is queried (GB/UK -> UK case law, PL -> Poland SAOS, anything else -> US CourtListener, the default). "UK" is accepted as a synonym for "GB" everywhere — it is normalized to the ISO code "GB" before it reaches the registry (GLEIF) lookup, since GLEIF itself only recognizes "GB". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses pricing ($0.03/call) and payment method (USDC on base), and mentions keyless sources. It describes the output format (one row per company with risk score). However, it could explicitly state the operation is read-only and non-destructive.
Agents need to know what a tool does to the 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 concise (one sentence with a dash) but includes pricing and payment info which is useful for selection. It is well-structured and front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 adequately describes the output (one row per company with risk score). It covers the main behavioral aspects (multiple checks, cost, keyless). Minor gaps: no mention of error handling or rate limits, but overall 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 coverage is 100%, so baseline is 3. The description adds significant value by explaining the default checks, the impact on API calls, and detailed behavior of jurisdictionHint (including synonym handling). This goes 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 clearly states it screens a counterparty by combining four specific checks (sanctions, registry, litigation, hiring) into one row with a risk score. It distinguishes from sibling tools which are individual checks, 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?
The description implies comprehensive screening in one call but does not explicitly state when to use this vs individual sibling tools. No when-not-to-use guidance is provided, though the existence of sibling tools suggests alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
email-verifierAInspectChecks email addresses: syntax, domain, and whether the domain publishes mail exchangers. Where mailbox-level existence cannot be established, the field is null rather than a guess. — $0.02/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| emails | Yes | Email addresses to verify. | |
| maxConcurrency | No | How many emails to check in parallel. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses a key behavioral trait: null for uncertain mailbox existence, avoiding guesses. However, it does not mention rate limits, authentication needs, or confirm safety. The pricing info adds 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?
Extremely concise: one sentence describing the core function plus pricing info. No fluff; 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?
The description covers the main purpose and a key behavior, but lacks any description of the output format (e.g., fields returned). Given no output schema, this is a minor gap. Overall, sufficient for 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% with descriptions for both 'emails' and 'maxConcurrency'. The tool description does not add new meaning beyond the schema; it reiterates the verification types but doesn't elaborate on parameter syntax or 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?
Description clearly states the tool checks email syntax, domain, and MX records. It is distinct from sibling tools which focus on corporate data, leaving no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description does not explicitly state when to use this tool over alternatives, it provides clear context on what it checks and notes a key behavior (null for undetermined mailboxes). The siblings are all business-oriented, so no direct competition exists, but usage guidance is still implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
funding-alertAInspectWatches funding announcements for a saved filter and returns only what changed since the previous check. The first run on a new filter creates the baseline and says so. — $0.05/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of filings requested per query, per run. | |
| queries | Yes | Company names or sector keywords to watch for new SEC Form D filings (e.g. "artificial intelligence", "biotech", or a specific company name). Every scheduled run re-checks these same queries and reports ONLY filings not seen on a previous run for this watch. | |
| max_items | No | Caps how many NEW-filing rows a single run will deliver and charge for, even if more were found. | |
| sinceDays | No | Only consider filings from the last N days when checking for matches — keep this generous (well beyond your run schedule) so a filing near the edge of the window is never missed because of clock drift between runs. | |
| baseline_key | No | A name for THIS watch, so you can run several independent filing watches from one Actor (e.g. "ai-startups", "biotech-seed") without one overwriting another's memory of what's already been seen. Each name is scoped to YOUR OWN Apify account. The prefilled value is only there so this Actor's own daily test run has a stable, obviously-a-test name; replace it with your own watch name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the first run creates a baseline and mentions cost. However, it lacks details on error handling, idempotency, or what happens if a filter returns no results.
Agents need to know what a tool does to the 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 only two sentences, with the core functionality in the first and supplementary details in the second. Every word earns its place, and no redundant information 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?
Given 5 parameters and no output schema, the description is minimal. It does not explain the return format or error scenarios. The schema provides parameter details, but the overall description could be more complete for a tool with 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 coverage is 100%, so baseline is 3. The main description adds context about the baseline_key parameter's first-run behavior but does not significantly enhance understanding beyond the already detailed schema descriptions. The cost mention is not directly 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?
The description clearly states the tool 'watches funding announcements for a saved filter and returns only what changed since the previous check.' This specifies both the resource (funding announcements) and the action (monitoring and returning incremental updates). It distinguishes itself from sibling 'funding-round-tracker' by emphasizing its incremental nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 recurring monitoring but does not explicitly state when to use or avoid this tool versus alternatives. The first-run behavior is noted, but there are no exclusions or comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
funding-round-trackerAInspectTrack recent SEC Form D filings by company name or sector keyword — the notice a company files when it raises private capital. Official SEC EDGAR full-text search, free, no API key or login. Get company, filing date and a direct document URL for every match. — $0.02/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of filings to return per query. | |
| queries | Yes | Company names or sector keywords to watch for new Form D filings (e.g. `artificial intelligence`, `biotech`, or a specific company name). One or more filing rows per query. | |
| sinceDays | No | Only include filings from the last N days. | |
| maxConcurrency | No | How many queries to process in parallel. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses key behaviors: it is a free official SEC EDGAR search, requires no login/API key, and costs $0.02/call. It does not explicitly state the operation is read-only, though 'track' and 'search' imply non-destructive behavior. Rate limits and error handling are not 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?
The description is two sentences with essential context front-loaded: main action, resource, and scope. It then adds utility info (returned fields, access method, cost) without fluff. Every sentence adds pertinent information for an AI agent deciding whether to invoke the 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?
Even without an output schema or annotations, the description provides sufficient context: what Form D is, what data will be returned (company, filing date, document URL), access requirements, and cost. It omits pagination/error details, but for a simple search tool this is fairly complete. The added context about private capital raises helps the agent understand relevance.
Complex tools with many parameters or behaviors need more documentation. Simple 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 parameter descriptions in the schema are already detailed (e.g., limit, sinceDays). The description reinforces that queries can be company names or sector keywords but does not add extra syntax or formatting details. It provides context on what Form D is, which indirectly helps understand parameter purpose, but the schema already 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+resource+scope: 'Track recent SEC Form D filings by company name or sector keyword.' It explains what Form D is, making the tool's purpose unmistakable. It also distinguishes itself from siblings by noting it uses official SEC EDGAR full-text search, free and without API key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 through the description: users should call this to find recent private capital raises via Form D filings. However, it does not explicitly state when to prefer this over alternatives (e.g., sibling 'funding-alert') or provide exclusion criteria. There is no direct comparison to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hiring-trend-indexCInspectA cross-section of hiring demand by role and geography, assembled from several job sources in one call. Partial results are marked partial and list what is missing. — $0.05/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| slices | Yes | What to snapshot and track. Two forms: "company:<ats-provider>:<token>" (e.g. "company:greenhouse:gitlab", "company:ashby:ramp") pulls a company's own public job board via this Actor's own live company-hiring-radar Actor. "board:<board-name>[:<keyword>]" (e.g. "board:xing-jobs", "board:jobs-ch-swiss:marketing") pulls a sample from one of this factory's own job-board Actors — see README for which board names are live today. Every run re-checks the SAME slices and reports what changed (by job function) since the last check for each one. | |
| watch_key | No | A name for THIS set of watches, so you can run several independent hiring-trend watches from one Actor without one overwriting another's memory of what it last saw. Scoped to YOUR OWN Apify account. The prefilled value is only there so this Actor's own daily test run has a stable, obviously-a-test name; replace it with your own. | |
| new_window_days | No | For company slices, how many days back a posting still counts as "new" in the underlying company-hiring-radar signal. Has no effect on board slices. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It notes partial results are marked, but omits authentication requirements, rate limits, destructive actions, or response details beyond a brief mention.
Agents need to know what a tool does to the 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 concise and front-loaded with core purpose, but includes non-functional pricing info that could be omitted for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 should explain return values. It only mentions partial results marking, missing details on output structure for a data-aggregating 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 description adds minimal value beyond the schema. The schema already explains parameters adequately, 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 clearly states it assembles a cross-section of hiring demand by role and geography from multiple sources. It distinguishes itself from sibling tools like company-hiring-radar by indicating aggregation, but does not explicitly contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 company-hiring-radar or other sibling tools. No mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
intent-signal-aggregatorAInspectIs this company in-market right now? Combines public hiring activity (Greenhouse, Lever, Ashby) and recent news (funding, launches, partnerships) into one intent score per company. No login, no API keys, no proxies. — $0.01/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| companies | Yes | One entry per company. Forms: `greenhouse:stripe` / `lever:x` / `ashby:y` (hiring signal from an ATS token), a plain company name like `Microsoft` (news signal only), or `Name|greenhouse:token` to get both hiring and news for the same company. | |
| maxConcurrency | No | How many companies to check in parallel. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It explicitly states no login, no API keys, no proxies, and reveals pricing via x402 (USDC on base), plus the underlying data sources. This gives the agent a clear picture of access requirements and operational costs beyond what any schema could convey.
Agents need to know what a tool does to the 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 question that immediately captures intent, followed by a concise explanation and pricing clause. Every sentence earns its place with no repetition or filler, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 there is no output schema and no annotations, the description covers purpose, input structure, security, and pricing. The only notable gap is the absence of output format details—it says 'one intent score per company' but does not specify the score range or response structure, which would be helpful for an agent invoking the 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 tool description adds minor context about news categories (funding, launches, partnerships) but the schema already thoroughly documents the parameter forms and meanings, including examples like `greenhouse:stripe` and `Name|ashby:token`. The description does not substantially improve parameter understanding 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 clearly and specifically states that the tool combines public hiring activity from Greenhouse, Lever, Ashby, plus recent news, into a single intent score per company. This distinguishes it from sibling tools like company-hiring-radar (likely hiring-only) and funding-alert (news-only) by explicitly emphasizing the aggregation of both signals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 opening question 'Is this company in-market right now?' establishes a clear use case and context for when the tool is appropriate. However, it does not explicitly mention when to avoid using it or name alternative tools for more narrow use cases, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
layoff-trackerAInspectTrack recent tech layoffs by company name or sector (e.g. "fintech", "AI") straight from Google News — a demand and recruiting signal. No login, no scraping, no proxies. Returns matched headlines, mention count and a one-line summary per query. — $0.01/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes | One entry per company name (e.g. "Google") or sector (e.g. "tech", "fintech"). Each is searched as "{query} layoffs" in Google News. | |
| sinceDays | No | Only count news published within this many days. | |
| maxConcurrency | No | How many queries to check in parallel. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the access method ('No login, no scraping, no proxies'), return content ('matched headlines, mention count, a one-line summary'), and cost ('$0.01/call'). It does not mention rate limits or data reliability, but for a read-only search tool this is respectable.
Agents need to know what a tool does to the 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, each earning its place: purpose and use case, return features, and pricing/payment. It is front-loaded and free of unnecessary 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 tool with no output schema, the description covers the key output elements ('headlines, mention count, one-line summary') and even pricing. It lacks details about output formatting or error handling, but given the simplicity of the tool, it is 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?
The input schema already describes all three parameters with 100% coverage, including the search pattern for 'queries' ('{query} layoffs' in Google News). The description adds no extra parameter-level 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?
The description clearly states the tool's function with a specific verb and resource: 'Track recent tech layoffs by company name or sector... Returns matched headlines, mention count and a one-line summary per query.' This unambiguously distinguishes it from sibling tools like funding-alert or hiring-trend-index, which cover different signals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 provides clear context for when to use: 'a demand and recruiting signal.' It also mentions the data source ('straight from Google News') and ease of use ('No login, no scraping, no proxies'). However, it doesn't explicitly state when not to use it or name alternative tools for other needs, 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.
lead-list-qualifierAInspectScores domains for buying readiness from several of our own signal sources in one call. Identity confidence is reported honestly as guessed when no override is supplied. — $0.05/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| domains | Yes | Company domains to score (e.g. "stripe.com"). Each domain fires 4 parallel checks (tech stack, hiring, funding mentions, contact info), so this is capped at 25 per run. | |
| role_keywords | No | Highlight domains currently hiring for roles matching these words (passed to our company-hiring-radar Actor, e.g. "sales", "marketing"). Leave empty to skip role matching. | |
| company_name_overrides | No | By default this Actor guesses each domain's ATS token / company name from the domain itself (e.g. "stripe.com" -> "stripe") for the hiring and funding checks — this is a best-effort heuristic, not a verified identity, and can be wrong. Use this field to override the guess for specific domains: {"my-startup.io": "mystartupinc"}. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds valuable context about identity honesty and pricing, but does not disclose whether the tool is read-only or has any safety implications beyond the costing note.
Agents need to know what a tool does to the 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 concise sentences plus a pricing line, with no filler. The purpose is front-loaded and every sentence adds 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?
The description covers cost, identity behavior, and parallel checks, but lacks information about the return format or structure, which would be helpful given no output 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?
All parameters are documented in the schema, and the description adds useful extra context: the domains parameter's parallel checks and cap, and the company_name_overrides parameter's guessing heuristic.
Input schemas describe structure but not intent. Descriptions should explain 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 tool scores domains for buying readiness from multiple signal sources, and distinguishes it from the many single-signal sibling tools by noting it aggregates several checks in one call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 combining signals, but does not explicitly state when to prefer this over alternatives like company-lookup or funding-alert, nor does it mention 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.
litigation-checkAInspectScreen a company for litigation history across US federal dockets (CourtListener), UK case law and Polish court judgments. Keyless, one row per company x jurisdiction, with the true case count and links to the source records. — $0.03/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| companies | Yes | Legal names of companies / counterparties to screen for litigation history. One row is produced per company per selected jurisdiction, up to your run's maximum charge (maxTotalChargeUsd) — if that budget runs out early, the remaining pairs are skipped and a final row explains why. Use the full legal name for the cleanest match (e.g. "Tesla, Inc." rather than "Tesla"). | |
| jurisdictions | No | Which court systems to check: US, UK, PL. US = federal PACER dockets via CourtListener (structural party-name search). UK = England & Wales / UK Supreme Court case law (structural party-name search, same guarantee as US). PL = Poland SAOS full-text judgment search — a keyword mention, not a confirmed party (see README). Any other code is returned as a free, graceful "unsupported jurisdiction" row rather than rejected — see the README for what's excluded and why. | |
| maxCasesPerRow | No | How many individual cases to list per company x jurisdiction row. caseCount reports the true total matched for US/PL (approximate above ~2000 matches — CourtListener's own count estimate), even when fewer are listed here; for UK it can be a lower bound when the output row's partial field is true (see README). | |
| maxConcurrency | No | How many companies to check in parallel. Each company's selected jurisdictions are always fetched in parallel with each other regardless of this setting. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the transparency burden. It discloses keyless usage, cost per call, budget behavior (skipping remaining pairs if budget exhausted), jurisdiction-specific search methods (US/UK: party-name search; PL: keyword mention), and the distinction between listed cases and true case count. It also explains unsupported jurisdiction 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?
The description is a single paragraph that front-loads the purpose and key details. It provides necessary operational info without excessive verbiage, though the pricing note could be considered extraneous. Overall, it earns its 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?
Given the absence of an output schema, the description explains the output format (one row per jurisdiction, true case count, links) and budget behavior. It could be more explicit about the exact return fields, but it is sufficient for an agent to understand the tool's capabilities.
Complex tools with many parameters or behaviors need more documentation. 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 input schema descriptions cover all 4 parameters in detail, achieving 100% coverage. The tool description adds minor context like 'Use the full legal name for the cleanest match' and budget-related notes, but does not significantly extend parameter understanding 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 clearly states the tool screens companies for litigation history across US, UK, and PL jurisdictions. It specifies 'one row per company x jurisdiction' and mentions keyless operation, cost, and output details, distinguishing it from sibling tools like sanctions-screening and patent-monitor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description provides operational details such as using full legal names, budget constraints, and jurisdiction-specific behavior, it does not explicitly state when to use this tool versus its siblings or when to avoid it. The guidance is implicit but lacks direct comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
new-company-detectorAInspectFind newly-incorporated UK companies matching a keyword, read from Companies House's public advanced-search results (active companies incorporated in the last ~60 days by default). No API key, no login, no proxies. — $0.02/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | Company-name keywords to search for (e.g. "capital", "ai", "consulting"). One entry per keyword; each returns every active company whose name contains it and that was incorporated within the search window. | |
| windowDays | No | Only return companies incorporated within this many days of today. | |
| maxConcurrency | No | How many keywords to search in parallel. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses that the tool performs a read operation from Companies House public results, requires no authentication, has a default search window, and includes pricing ($0.02/call). This is useful context beyond a generic 'find companies' statement, though it omits details like rate limits or result format.
Agents need to know what a tool does to the 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 immediately states what the tool does, followed by a brief pricing note. Every word contributes value, with no repetition of schema details or unnecessary 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?
Given the tool's simplicity (3 parameters, no output schema), the description provides a solid overview: source, default behavior, authentication requirements, and pricing. It doesn't cover edge cases or return format, but for selection and invocation purposes it is sufficiently complete, especially with schema covering 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 baseline is 3. The description adds no additional meaning beyond the schema—it mentions 'keyword' and the default window, which are already covered by the items and windowDays parameter descriptions. The schema already clearly documents each parameter's purpose and 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 clearly states the tool's verb ('Find') and resource ('newly-incorporated UK companies matching a keyword'), and specifies the source (Companies House public advanced-search results) and default window (~60 days). This distinguishes it from sibling tools like company-lookup by emphasizing recency and the no-auth access 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?
The description implies usage for discovering recent UK company incorporations and mentions 'No API key, no login, no proxies' as a convenience, but it does not explicitly state when to use this tool over alternatives like company-lookup or how it differs from company-registry-enricher. No exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
patent-monitorAInspectWatch keywords or technologies for newly granted US patents. Bring your own free PatentsView API key — get patent id, title, grant date, assignee and a direct Google Patents link for every match, sorted by most recent. Official PatentsView Search API (USPTO-backed). — $0.02/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many patents to fetch per query, most recently granted first. | |
| queries | Yes | Tech keywords or technologies to watch (e.g. `quantum computing`, `mRNA vaccine`). One or more matching patent rows per query. | |
| sinceDays | No | Only include patents granted within N days. | |
| maxConcurrency | No | How many queries to process in parallel. | |
| patentsviewApiKey | No | Optional. Leave empty to use the keyless Google Patents source (worldwide). Provide your own free PatentsView key (https://patentsview.org/query-builder) to use the official USPTO-backed source (US patents, more results/query). Sent only in the X-Api-Key header — never logged or stored. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It adds useful operational details: the need for a PatentsView API key, the cost per call, and the official USPTO-backed source. However, it does not explicitly mention read-only behavior, rate limits, error handling, or what happens when the key is missing. This is a moderate level of 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?
The description is two sentences that front-load the purpose and then provide key operational details (API key, output fields, sorting, pricing). Every clause contributes meaningful information with no fluff 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?
Given there is no output schema, the description compensates by summarizing the return fields. It covers the source, pricing, and scope. It does not describe the exact result structure (e.g., JSON vs CSV) or error behavior, but the core functionality and operational costs are well communicated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters have schema descriptions with 100% coverage, so the baseline is 3. The description adds a note about 'sorted by most recent,' which relates to limit/sinceDays, but does not introduce new parameter semantics 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 tool's function: 'Watch keywords or technologies for newly granted US patents.' It also specifies the output fields (patent id, title, grant date, assignee, Google Patents link) and the sorting order, which robustly distinguishes it from sibling tools focused on companies, funding, or sanctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 provides clear context for when to use the tool: monitoring new US patents by keyword/technology. It specifies the geographic scope ('US patents') and recency. It does not explicitly mention alternatives or when not to use it, but the domain is distinct from all sibling tools, so the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pricing_infoAInspectFree — list every paid tool in the 'company-intel' bundle with its price, payTo address and network. Call this first if you don't have a wallet ready yet.
| 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 adds useful behavioral context by stating it is 'Free' and implies no wallet is needed, which is a meaningful distinction from other tools. It does not mention response format or side effects, but for a simple read-only list that is sufficient.
Agents need to know what a tool does to the 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, front-loaded with 'Free' and an actionable verb. Every word adds value, and there is no repetition of schema information or unnecessary detail. It is a model of concise writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 tool with no parameters and no output schema, the description is mostly complete: it states what is returned and when to call. It could be more complete by specifying the return format or that it is a read-only operation, but given the low complexity, the information provided is 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?
The tool has zero parameters, and the empty schema leaves nothing to explain. Per the scoring rubric, 0 params earns a baseline of 4. The description naturally does not add parameter information because none exist.
Input schemas describe structure but not intent. Descriptions should explain 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 tool lists all paid tools in the 'company-intel' bundle with price, payTo address, and network. The verb 'list' and specific resource/fields make the purpose unmistakable, and it stands apart from sibling tools that focus on company data, hiring, funding, 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?
It provides explicit usage context: 'Call this first if you don't have a wallet ready yet.' This tells the agent when to invoke the tool, though it does not explicitly name alternatives or when-not-to-use it. The guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sanctions-screeningAInspectScreen names against the live OFAC SDN and EU consolidated sanctions lists. Keyless, no login — flags potential hits with a match score so you can review before onboarding a client or counterparty. — $0.01/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes | Person or company names to screen against the OFAC SDN and EU consolidated sanctions lists, one per row. | |
| minScore | No | Only report candidate matches scoring at or above this (0 = report everything, 1 = only a full token match). Kept soft on purpose — a missed hit is worse than a false one. At the default 0.5, a two-word name matching on one word still surfaces as a low-confidence hit. | |
| maxConcurrency | No | How many names to screen in parallel. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It adds that the tool is 'Keyless, no login' and costs '$0.01/call, x402 (USDC on base),' which is useful. However, it does not explicitly state that it is a read-only operation or explain error/rate-limit behavior, leaving a transparency 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 two sentences, front-loaded with the core action, and wastes no words. It packs the live lists, match score, use case, auth, and pricing into a compact, readable format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 description covers the essential facets: what it screens, why use it, auth requirements, and cost. It also hints at the output ('flags potential hits with a match score'). However, without an output schema, it could be more explicit about the exact return structure and handling of edge cases, but overall it is adequate for 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?
The input schema provides descriptions for all three parameters (names, minScore, maxConcurrency) with 100% coverage, so the schema already defines meaning. The description mentions 'match score' but does not add parameter-specific semantics beyond the schema, placing it at 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 begins with 'Screen names against the live OFAC SDN and EU consolidated sanctions lists,' which is a specific verb+resource. It clarifies the purpose by mentioning 'flags potential hits with a match score' and the onboarding context, distinguishing it from sibling tools like litigation-check or counterparty-risk-rollup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 provides clear context: 'so you can review before onboarding a client or counterparty,' indicating when to use it. It notes 'Keyless, no login' as a usability feature but does not explicitly name alternatives or exclusions, so it stops short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sanctions-update-alertAInspectRe-screens a saved watchlist against sanctions lists and returns only the entries whose status changed since the previous check. The first run creates the baseline and says so. — $0.05/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes | Person or company names to watch against the OFAC SDN and EU consolidated sanctions lists, one per row. Every scheduled run re-screens these same names and reports ONLY what changed since a previous run of this watch: a new hit, a hit that disappeared, or an existing hit's score/program/alias shifting. | |
| minScore | No | Only consider candidate matches scoring at or above this (0 = everything, 1 = only a full token match). Kept soft on purpose — a missed hit is worse than a false one. | |
| max_items | No | Caps how many new-hit / changed-hit rows a single run will deliver and charge for, even if more were found. | |
| baseline_key | No | A name for THIS watch, so you can run several independent screening watches from one Actor (e.g. "vendor-list", "new-hires") without one overwriting another's memory of what's already been seen. Each name is scoped to YOUR OWN Apify account. The prefilled value is only there so this Actor's own daily test run has a stable, obviously-a-test name; replace it with your own watch name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses cost per call and baseline creation, but omits details like what happens if no changes, how state is stored, authorization needs, or idempotency. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two short sentences plus a cost note. Information is front-loaded with the core purpose. 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?
Missing output schema, but description mentions return values are changed entries. Does not specify format or edge cases. For a tool with 17 siblings, more detail on output and scope would help. Adequate for its 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 each parameter has a helpful description. The tool description itself does not add additional meaning beyond what's in the schema. Baseline score 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?
Description clearly states it re-screens a saved watchlist and returns only changed entries. Verb 're-screens' and resource 'saved watchlist' are specific, and the function (delta-only reporting) distinguishes it from sibling 'sanctions-screening' which likely does full screening.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for ongoing monitoring by mentioning baseline creation and change detection, but does not explicitly state when to use this vs alternatives like a one-time screening tool. No exclusion criteria or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
website-contact-extractorAInspectExtract public contacts a company posted on its own site: email, phone, social links — with an honesty check that flags third-party/placeholder addresses instead of selling them as the company's own. — $0.02/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| domains | Yes | Company domains or URLs to check (e.g. `example.com` or `https://example.com`). Path/query is ignored — the Actor visits its own fixed set of pages (home, contact, about). | |
| checkPages | No | Override which subpages to visit per domain (each must start with `/`, or be empty for the homepage). Default: homepage, /contact, /contact-us, /about (+ /impressum automatically for .de/.at/.ch domains). | |
| maxConcurrency | No | How many domains to check in parallel. | |
| maxPagesPerDomain | No | How many pages to visit per domain at most. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description discloses key behaviors: visits fixed pages (home, contact, about), performs an honesty check to flag third-party/placeholder addresses, and mentions pricing. It does not cover rate limits or failure modes, but is fairly 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 description is a single sentence that efficiently states purpose and key features. Including pricing is somewhat extraneous but not overly verbose. It front-loads the primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 only vaguely mentions output (email, phone, social links) without describing structure, failure handling, or edge cases. For a 4-parameter tool, it is adequate but lacks depth.
Complex tools with many parameters or behaviors need more documentation. Simple 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 detailed parameter descriptions. The tool description does not add additional meaning beyond what the schema provides for parameters, so baseline score 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 clearly states it extracts public contacts (email, phone, social links) from a company's own site, and includes a distinctive honesty check feature. This distinguishes it from siblings like email-verifier or 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?
The description explains what the tool does and highlights the honesty check, but does not explicitly state when to use it versus alternatives, nor any conditions for not using it. Usage guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
