Skip to main content
Glama
minghsuy

ctscout

by minghsuy

Search ctscout by multiple company names in one call

ctscout_search_company_batch
Read-only

Look up apex domains for multiple company names in a single batch call, with partial matching and results returned in input order.

Instructions

Look up apex domains for up to 10 organization names in a single call, via ctscout.dev's /scan/batch endpoint. Each name is matched exactly like ctscout_search_company; results come back in input order.

Args:

  • company_names (string[], required): 1–10 organization names. Partial matches work — 'Goldman' matches 'Goldman Sachs'. Each 2–200 chars.

  • response_format ('markdown' | 'json', default 'markdown'): output format.

Returns (on success, structuredContent follows the declared outputSchema; an error result — 401, 429, timeout — is isError with no structuredContent, so never dereference snapshot on a failed call):

  • "Attributed" and "candidate" mean exactly what they mean in ctscout_search_company: what the evidence names (the OV/EV certificate subject on /scan, both tiers) vs a semantic name-similarity guess that is NOT an attribution.

  • In markdown: a snapshot line, then one section per company (heading + the same attributed-domains table as ctscout_search_company; a candidate-organizations table when that name's match_type is 'semantic'), followed by remaining quota. Names that failed render an error line instead of a table.

  • In JSON, the batch envelope: { "results": [ { "query": {...}, "domains": [...], "total": number, "match_type": "exact"|"semantic"|"none", "candidates"?: [...] }, // same per-result fields as ctscout_search_company { "query": {...}, "error": { "code": number, "message": string } } ], "remaining_quota": number | null, // null = no remaining count reported (Pro today); a per-day request guard still applies "snapshot": string | null, // sync date shared by every result in the batch (API version 2026-09-05+); null (unknown freshness) only when the API could not determine it "snapshot_source": "scan" | "unavailable" }

Partial-failure semantics (important):

  • This is a 207-style mixed-result envelope, NOT all-or-nothing: one name can fail (its result carries an "error" object with no "domains") while the rest succeed.

  • Quota debits by the number of names in the batch — every name counts once, even zero-result ones. No free riders.

Examples:

  • Use when: "Look up Cloudflare, Fastly, and Akamai" -> { company_names: ["Cloudflare", "Fastly", "Akamai"] }

  • Don't use when: you have a single name (use ctscout_search_company) or a specific domain (use ctscout_lookup_domain).

Auth & limits:

  • Requires an API key in CTSCOUT_API_KEY, same as ctscout_search_company.

  • Oversized batches (>10 names) are rejected with a validation error before any network call and without a partial quota debit.

  • This MCP batch tool intentionally accepts names only. For matching modifiers such as strict_match_org_only, purpose, or org_match_mode, use individual ctscout_search_company calls or the REST /scan/batch endpoint.

Legal-vs-brand and coverage caveats are identical to ctscout_search_company — brand names may need legal-entity variants ("X Companies", "X Group", "The X"), and coverage is best for established US/EU entities with OV/EV certs.

Corrections:

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
company_namesYesCompany / organization names to look up in one call (1–10). Each is matched exactly as in ctscout_search_company (partial, case-insensitive). Results come back in input order; individual names can fail independently (partial-failure envelope), so a failed name doesn't sink the batch.
response_formatNoOutput format: 'markdown' for a per-company summary, 'json' for the raw batch envelope (useful for programmatic processing).markdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultsYesOne item per input name, in input order.
snapshotYesWarehouse/D1 sync date (YYYY-MM-DD) the answer was read from; the warehouse syncs daily. null when the API could not determine it.
remaining_quotaYesnull = the API reported no remaining count for this key (Pro today); a per-day request guard still applies, and a 429 carries the API's own detail.
snapshot_sourceYes'scan' = the API response carried the date; 'unavailable' = it did not, snapshot is null and must be treated as unknown, never as current.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.0

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description details partial-failure semantics (207-style envelope), per-name quota debits with no free riders, snapshot freshness behavior, and error handling. It also discloses correction channels and coverage caveats, exceeding annotation transparency.

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?

The description is lengthy but well-organized with clear sections (Examples, Auth & limits, Partial-failure semantics, Corrections). Every part serves a purpose given the tool's complexity; however, some redundancy exists (e.g., repeated caveats tied to ctscout_search_company), making it slightly less concise than optimal.

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?

The description comprehensively covers all necessary context: mixed-result envelope structure, quota accounting, snapshot details, auth, limits, error behavior, distinctions from related tools, and how to report issues. Even with an output schema present, the description fully explains the response shape, exceeding the minimum requirement.

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

Parameters5/5

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

Both parameters are fully described in the schema and further elaborated in the description: company_names includes range, matching behavior, order, and independent failure; response_format explains default and use cases. Schema coverage is 100% and the description adds important context like case-insensitivity and partial matches.

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 description clearly states the action ('Look up apex domains'), the resource (up to 10 organization names via /scan/batch), and explicitly distinguishes from siblings: single names go to ctscout_search_company, specific domains to ctscout_lookup_domain. The batch nature is unmistakable.

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?

Provides concrete when-to-use examples ('Look up Cloudflare, Fastly, and Akamai'), when-not-to-use instructions, authentication requirements (CTSCOUT_API_KEY), and batch size limits. Quota-debit semantics and partial-failure handling are explained, leaving no ambiguity about usage.

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