Skip to main content
Glama

Detect AI Tooling

detect_ai_tooling
Idempotent

Identify how far a company has adopted AI from its domain, returning maturity tier, detected vendors, llms.txt status, crawler policy, and evidence for outbound qualification.

Instructions

Given a company domain, determine how far that company has gone with AI. Returns an ai_maturity tier of none, declared (says AI but nothing observable is running), deployed (AI tooling is live on the site), or commercialized (the pricing page charges for AI via credits, tokens, an add-on, an AI-named plan, or a per-outcome price), plus the detected AI vendors, validated llms.txt status, robots.txt AI-crawler policy, and the evidence behind the verdict. A domain behind a bot challenge returns blocked=true at low confidence rather than a false negative. Returns flat, Clay-ready JSON. Reads public data and writes nothing; requires an APIFY_TOKEN and consumes Apify credits per domain analyzed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainNoCompany domain to analyze, without https or www, e.g. intercom.com.
domainsNoBatch mode: several company domains analyzed in one call. Takes precedence over domain.
vendorsNoReport only these AI vendors. Omit to report every one. Detection is unchanged, so filtering costs nothing extra. The ai_maturity verdict, llms.txt, robots.txt, and pricing reads are site wide and never narrowed by this.
skipCacheNoForce a fresh analysis and ignore the 7 day result cache.
check_pricingNoFetch and score the pricing page. Default true. Setting this false is faster but caps the result at 'deployed', because 'commercialized' can only be proven on a pricing page.
max_charge_usdNoOptional spending cap for this call, in USD, passed to the actor as max_charge_usd. The run stops before any charge that would take it past this amount and keeps every row already charged. Leave empty to rely only on the maximum charge per run set on your Apify account.
request_timeout_msNoPer-request timeout in milliseconds. 3000 to 20000. Default: 9000.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.14.0
    • addedInput schema / properties / max_charge_usd
      Added value: +{
      +  "description": "Optional spending cap for this call, in USD, passed to the actor as max_charge_usd. The run stops before any charge that would take it past this amount and keeps every row already charged. Leave empty to rely only on the maximum charge per run set on your Apify account.",
      +  "minimum": 0,
      +  "type": "number"
      +}
  2. Addedv1.1.1

TDQS

A4.2/5.0
Behavior5/5

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

Goes well past the annotations by disclosing auth requirements (APIFY_TOKEN), cost behavior (consumes Apify credits per domain), the 7-day cache, and the blocked=true low-confidence path instead of a false negative. It also states it reads public data and writes nothing to the target domain, which is nuanced against readOnlyHint=false (the run itself spends credits) but not a direct misrepresentation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the maturity taxonomy are front-loaded, then it layers output contents, an edge case, and operational constraints. It is a dense single block that is longer than strictly needed, but nearly every sentence carries distinct information.

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

Completeness5/5

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 carries the return-shape burden by naming the fields an agent receives (tier, vendors, llms.txt status, robots.txt policy, evidence, blocked). Combined with the auth and cost notes, nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter already carries its own documentation, making the baseline 3. The description reinforces the key semantics (vendors filter costs nothing extra, check_pricing caps the tier at 'deployed', batch mode precedence) but adds little that the schema doesn't already state.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource (analyze a company domain for AI adoption) and enumerates the exact output taxonomy: an ai_maturity tier of none/declared/deployed/commercialized. That level of specificity lets an agent separate it from the neighboring detect_gtm_tech_stack, which covers general GTM stack rather than AI adoption depth.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied rather than stated: batch mode 'takes precedence over domain', skipCache forces a fresh run, and check_pricing=false is only worth setting when 'deployed' is an acceptable ceiling. There is no explicit when-to-use/when-not or a named alternative among the many sibling detection tools.

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