Skip to main content
Glama

Find buying intent

find_intent
Destructive

Screen up to 25 company domains for dated buying signals: hiring (live job posts with evidence URLs), funding, news, job_change. For angles, what's changed, how to approach, or why now on one company or person, use research_company (a company) or prospect_picture (a person, their company, or both) instead. Leave signals out unless a family must be checked on every company: by default only hiring is checked, a company that is not hiring costs nothing, and a hiring company's latest funding round comes with it (the others list funding under skipped_signals). A company with a current hiring signal costs 11 credits. Each paid check you ask for explicitly (funding on a company that is not hiring, news, job_change, technology) costs 13 credits whatever it finds; hiring checks that find nothing, and failed checks, are free; result.domain_status[].charge shows what each company cost. Recency: signals observed inside since / within_days (default 180 days) are current; older ones return under result.historical as context. Each news signal carries news_type, the kind of news it is: funding | product | partnership | customers | expansion | leadership | layoffs | acquisition | challenges | recognition | other. roles filters hiring by job title (literal match). technology is DEPRECATED (a present-day vendor detection with no adoption date, not a buying signal; use find_companies technologies). audience is an optional goal: what you sell and to whom. It never changes charges. With a goal, ranking.by says goal when signals were judged for it, otherwise recency (today’s order); why_now requires a date within 60 days, and why_now_basis says judged or date. Unavailable or unsure judgments use the date rule. budget_credits is a spend ceiling, never permission to use a dearer source: above it, the call is refused before anything is reserved, and no company you sent is dropped to fit. dry_run: true returns the plan instead (the most the call can cost, how many sources could answer, and each limit it would trip) with nothing looked up, reserved or charged. Example: {"company_domains":["acme.com","example.io"]}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rolesNoHiring role filter, up to 25 job titles or phrases: a hiring post counts only when it is one of these roles. Put a role in double quotes to match it word for word. Applies to hiring only; job_change events carry no structured role field.
sinceNo
dry_runNoReturn this call's plan instead of running it, as of evaluated_at: the most it can cost, how many sources could answer, what budget_credits changes, and every limit the real call would trip. Nothing is looked up, reserved or charged, and a later call may differ. Where previews aren't available to this key yet, a request that sets it is refused with the reason.
signalsNoSignal families to check. hiring = live job posts with evidence URLs; funding, news, job_change = dated events. Omit it to check hiring first: only hiring is checked, and a hiring company's latest funding round comes with it; list funding explicitly to check every company (a paid check). DEPRECATED: technology — a present-day vendor detection with no adoption date, not a buying signal; use find_companies.technologies instead. Still accepted in v1.
audienceNoOptional goal: what you sell and to whom. Always accepted. Until goal ordering is available, signals keep today’s order with ranking.by recency and date-based why_now flags; no change to charges.
within_daysNo
budget_creditsNoSpend ceiling for this call, in credits. If the most the call can cost is above it, the call is refused before anything is reserved or charged. No company you sent is dropped to fit. It is a ceiling only: it never lets the call use a dearer source. Where spend ceilings aren't available to this key yet, a request that sets it is refused with the reason.
company_domainsYes
idempotency_keyNoA payment_required refusal means services are stopped for unpaid billing; direct the owner to the billing link in the error. Campaigns stay paused after payment until restarted. Optional for search and enrichment tools: supply one so a retry returns the original result without paying again; if that call failed with provider_unavailable, rate_limited or insufficient_credits (after a top-up), a retry runs it once more after its cooldown (30 s, or a longer retry_after_seconds; insufficient_credits as soon as the balance covers it), unless its provider may already have done the work. Required for tools that create an external side effect; reuse the same value after a timeout or an approval. A stored failure comes back with details.replayed: true; with retry_after_seconds, retry the same value after that.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"Optional for search and enrichment tools: supply one so a retry returns the original result without paying again; if that call failed with provider_unavailable, rate_limited or insufficient_credits (after a top-up), a retry runs it once more after its cooldown (30 s, or a longer retry_after_seconds; insufficient_credits as soon as the balance covers it), unless its provider may already have done the work. Required for tools that create an external side effect; reuse the same value after a timeout or an approval. A stored failure comes back with details.replayed: true; with retry_after_seconds, retry the same value after that."New value: +"A payment_required refusal means services are stopped for unpaid billing; direct the owner to the billing link in the error. Campaigns stay paused after payment until restarted. Optional for search and enrichment tools: supply one so a retry returns the original result without paying again; if that call failed with provider_unavailable, rate_limited or insufficient_credits (after a top-up), a retry runs it once more after its cooldown (30 s, or a longer retry_after_seconds; insufficient_credits as soon as the balance covers it), unless its provider may already have done the work. Required for tools that create an external side effect; reuse the same value after a timeout or an approval. A stored failure comes back with details.replayed: true; with retry_after_seconds, retry the same value after that."
  2. Changed1 schema field changed
    • addedInput schema / properties / audience
      Added value: +{
      +  "description": "Optional goal: what you sell and to whom. Always accepted. Until goal ordering is available, signals keep today’s order with ranking.by recency and date-based why_now flags; no change to charges.",
      +  "type": "string"
      +}
  3. Changed2 schema fields changed
    • addedInput schema / properties / budget_credits
      Added value: +{
      +  "description": "Spend ceiling for this call, in credits. If the most the call can cost is above it, the call is refused before anything is reserved or charged. No company you sent is dropped to fit. It is a ceiling only: it never lets the call use a dearer source. Where spend ceilings aren't available to this key yet, a request that sets it is refused with the reason.",
      +  "exclusiveMinimum": 0,
      +  "maximum": 2000,
      +  "type": "number"
      +}
    • addedInput schema / properties / dry_run
      Added value: +{
      +  "description": "Return this call's plan instead of running it, as of evaluated_at: the most it can cost, how many sources could answer, what budget_credits changes, and every limit the real call would trip. Nothing is looked up, reserved or charged, and a later call may differ. Where previews aren't available to this key yet, a request that sets it is refused with the reason.",
      +  "type": "boolean"
      +}
  4. Changed1 schema field changed
    • addedInput schema / properties / roles / description
      Added value: +"Hiring role filter, up to 25 job titles or phrases: a hiring post counts only when it is one of these roles. Put a role in double quotes to match it word for word. Applies to hiring only; job_change events carry no structured role field."
  5. Changed1 schema field changed
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"Optional for search and enrichment tools: supply one to make a retry replay the original result. Required for tools that create an external side effect; reuse the same value after a timeout or an approval."New value: +"Optional for search and enrichment tools: supply one so a retry returns the original result without paying again; if that call failed with provider_unavailable, rate_limited or insufficient_credits (after a top-up), a retry runs it once more after its cooldown (30 s, or a longer retry_after_seconds; insufficient_credits as soon as the balance covers it), unless its provider may already have done the work. Required for tools that create an external side effect; reuse the same value after a timeout or an approval. A stored failure comes back with details.replayed: true; with retry_after_seconds, retry the same value after that."
  6. Changed4 schema fields changed
    • addedInput schema / properties / roles
      Added value: +{
      +  "items": {
      +    "maxLength": 120,
      +    "minLength": 1,
      +    "type": "string"
      +  },
      +  "maxItems": 50,
      +  "type": "array"
      +}
    • changedInput schema / properties / signals / description
      Previous value: -"Signal families to check. hiring = live job posts with evidence URLs; funding, news, job_change = dated events. DEPRECATED: technology — a present-day vendor detection with no adoption date, not a buying signal; use find_companies.technologies instead. Still accepted in v1."New value: +"Signal families to check. hiring = live job posts with evidence URLs; funding, news, job_change = dated events. Omit it to check hiring first: only hiring is checked, and a hiring company's latest funding round comes with it; list funding explicitly to check every company (a paid check). DEPRECATED: technology — a present-day vendor detection with no adoption date, not a buying signal; use find_companies.technologies instead. Still accepted in v1."
    • addedInput schema / properties / since
      Added value: +{
      +  "format": "date",
      +  "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
      +  "type": "string"
      +}
    • addedInput schema / properties / within_days
      Added value: +{
      +  "maximum": 730,
      +  "minimum": 1,
      +  "type": "integer"
      +}
  7. Changed3 schema fields changed
    • changedInput schema / properties / company_domains / maxItems
      Previous value: -200New value: +50
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"Stable retry key; the same value identifies retries of the same request after timeout or approval."New value: +"Optional for search and enrichment tools: supply one to make a retry replay the original result. Required for tools that create an external side effect; reuse the same value after a timeout or an approval."
    • addedInput schema / properties / signals / description
      Added value: +"Signal families to check. hiring = live job posts with evidence URLs; funding, news, job_change = dated events. DEPRECATED: technology — a present-day vendor detection with no adoption date, not a buying signal; use find_companies.technologies instead. Still accepted in v1."
  8. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With annotations already flagging destructiveHint=true, the description goes far beyond them: it prices each path (11 credits for a hiring company, 13 per explicit paid check), states which checks are free (hiring misses, failed checks), explains budget_credits refusal-before-reservation semantics, dry_run's no-charge plan, and recency/historical split. This is the kind of cost-and-side-effect disclosure the destructiveHint annotation only hints at.

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

Conciseness3/5

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

Front-loaded and every sentence is substantive, but it is delivered as one unbroken ~350-word block interleaving pricing, deprecation, recency, ranking, and refusal rules. There is no structural separation (no lines for cost, defaults, or return fields), so scanning for a specific rule is hard despite low redundancy.

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?

There is no output schema, so the description carries the return burden and does: result.domain_status[].charge, result.historical, skipped_signals, news_type values, ranking.by, and why_now_basis are all explained. For a 9-parameter, credit-spending, open-world tool, an agent has everything needed to call it safely.

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

Parameters4/5

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

Schema coverage is 67%, and the description fills many gaps: signals defaults and the DEPRECATED technology note, roles as literal job-title match, audience as a charge-neutral goal, and how ranking.by / why_now_basis behave with a goal. It does not mention idempotency_key at all, and its 'up to 25 company domains' conflicts with the schema's maxItems of 50, a count an agent could rely on incorrectly.

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

Purpose5/5

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

The opening sentence states a concrete verb and resource — 'Screen up to 25 company domains for dated buying signals' — and enumerates the signal families (hiring, funding, news, job_change). It also names the two siblings it is not (research_company for a company angle, prospect_picture for a person), so an agent can route 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.

Usage Guidelines5/5

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

Explicit when-to-use and when-not-to-use: 'For angles, what's changed, how to approach, or why now... use research_company... or prospect_picture instead.' It also gives a default-behavior rule ('Leave signals out unless a family must be checked on every company') that tells the agent which invocation is the cheap/correct one.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources