openosint

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

With no annotations provided, the description carries the full behavioral burden, and it does disclose the most operationally important trait: URLs are built locally and nothing is transmitted, making the call safe and repeatable. It omits secondary traits such as how many dorks are produced, deduplication, or whether any file is written.

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

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

Two short sentences with zero filler; the purpose is front-loaded and the safety posture is appended compactly as "[passive] ... sends nothing." Nothing could be removed without losing information.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter URL generator with no output schema and no annotations, the description covers what it produces (dork URLs), the accepted inputs, and the local/no-network behavior. Minor gaps remain around output shape (list vs single URL) and result volume, but nothing critical for correct invocation.

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

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

Schema coverage is 50%: json_output is documented in the schema, but target is a bare string with no schema description. The description compensates by enumerating the accepted target forms (name, email, username, domain), which is exactly the missing semantics an agent needs.

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

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

States a specific verb and resource ("Generate targeted Google dork URLs") and enumerates the accepted target types (name, email, username, domain), so the agent knows exactly what the tool produces. It does not name the obvious sibling search_dorks_live, though the "[passive] ... sends nothing" note implicitly distinguishes local generation from a live query.

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

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

Usage is implied by "for any target (name, email, username, domain)" and by the passive/local framing, which hints this is the safe pre-step before a live search. However, no explicit when-to-use condition or named alternative (e.g., search_dorks_live) is given, so the agent must infer the routing decision.

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

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

With no annotations, the description carries the full burden and largely succeeds: it declares [passive], states it reads the local graph database only, specifies the install dependency, and explains what exclusion does (omit every breach-derived fact). It is silent on scale/streaming behavior for a potentially huge graph, which keeps it below 5.

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

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

The core action and output format are front-loaded, and each subsequent sentence adds distinct value (exclusion semantics, dependency requirement, read-only scope). No filler.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without annotations or an output schema, the description must supply the behavioral and output contract, and it does describe the line format and .ftm compatibility. Remaining gaps are secondary details like error behavior when the extra is missing or handling of very large graphs.

Complex tools with many parameters or behaviors need more documentation. Simple 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 already 100%, so the baseline is 3; the description adds real meaning by giving a worked example for exclude_datasets ('openosint:hibp') and clarifying that whole datasets are omitted, including derived facts. json_output is left to the schema.

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

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

States a specific verb (export), a specific resource (the additive FollowTheMoney entity graph / openosint.graph), and the exact output format (newline-delimited JSON, one FtM entity per line). This is clearly distinguishable from the search_* and graph_neighbors siblings, which query rather than bulk-export.

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

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

Conveys usage context (bulk export for downstream .ftm tooling, reads the local DB only, needs the 'graph' extra) and a concrete exclusion example, but never states when to prefer this over graph_neighbors or graph_review_candidates, nor any when-not conditions. Usage is implied rather than spelled out.

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

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

With no annotations, the description carries the full burden and largely meets it: it marks the operation as passive, states it reads the local graph database only (no network), discloses the install-time dependency, and enumerates the return shape. It stops short of stating result-size limits, pagination, or what happens when the entity id is absent from the graph.

Agents need to know what a tool does to the 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 dense sentences, front-loaded with the core traversal behavior before the cross_layer option, dependency note, and safety marker. Every clause carries information, though the closing '[passive]' fragment is terse to the point of being cryptic.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description must cover returns, and it does by naming entities, edges, and the per-edge provenance fields. Combined with the dependency note and the cross_layer explanation, an agent has enough to invoke it correctly; only cardinality/limits are unaddressed.

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

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

Schema coverage is 75% and entity_id has no schema description, so the description meaningfully compensates by identifying it as a FollowTheMoney entity id. It also enriches cross_layer beyond the schema's one-liner by naming what the bridge links actually are (IPs, domains, hashes), while depth's cap is already documented in the schema.

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

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

States a specific verb (traverse), the exact resource (FollowTheMoney entity graph), the entry point (one entity id), the scope (to a given depth), and what comes back (entities, edges, per-edge provenance). This is clearly distinguishable from the search_* siblings, which are external lookups, and from graph_export/graph_review_candidates.

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

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

It gives one explicit conditional: set cross_layer=true to reach the raw infra correlation graph, and it notes the 'graph' extra prerequisite. However, it never routes the agent among the sibling graph tools (graph_export, graph_review_candidates) or explains when a neighbor traversal beats a fresh external search, leaving the core when-to-use decision to inference.

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

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

With no annotations, the description carries the full burden and does much of it: it discloses that 'accept' merges the pair, that 'reject' permanently excludes it from future suggestions (an irreversible side effect), and that nothing auto-merges. The trailing '[passive] Reads the local graph database only' tag sits awkwardly against the merge-write behavior of 'decide', and permissions/auth requirements and pagination are not covered, keeping it below 5.

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

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

Purpose is front-loaded in the first sentence, followed by a tight action-by-action breakdown and a critical constraint sentence. It is dense but every sentence adds a fact an agent needs, with no filler.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter tool with no output schema and no annotations, the description covers actions, filters, verdict semantics and the no-auto-merge constraint well. Minor gaps remain: return shape is only sketched for 'list', and there is no mention of permissions, pagination, or the ambiguous '[passive]' classification.

Complex tools with many parameters or behaviors need more documentation. Simple 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 already 80%, so the baseline is 3; the description adds real meaning on top by mapping filters (schema, score range, dataset) to the 'list' action and mapping entity_id/canonical_id/decision/reviewer_id to the 'decide' action. It also explains that decision='accept' means merge and 'reject' means permanent exclusion, which the bare enum values do not convey.

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

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

States a specific resource and role: a 'human review queue for suggested same_as entity matches' produced by graph-dedup. This clearly distinguishes it from the sibling search_* tools and from graph_export/graph_neighbors, so an agent can identify it without opening the schema.

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

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

The description splits the tool by action and gives the condition for each: action='list' to browse pending candidates with filters, action='decide' to record a verdict. It also states the key selection fact that only this action can write judgement='positive'. It stops short of naming sibling alternatives to avoid (e.g. graph_neighbors for pure exploration), so it is strong but not fully exhaustive.

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

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

With no annotations, the description carries the full burden and does so well: it discloses parallel execution, per-target report files plus a summary report, the 10-target cap, the ANTHROPIC_API_KEY requirement, a shared tool-call cap per agent, and passive-by-default behavior unless active is enabled. Gaps remain around failure handling and cost, keeping it short of a 5.

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

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

The description is front-loaded with the core action and packs behavioral detail into a compact block. The stray '[inherits]' token and the dense final sentence slightly reduce readability.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parallel orchestrator with no output schema, the description adequately covers outputs (per-target reports plus a summary), execution model, limits, and auth. Only error/failure behavior for individual targets is left unaddressed.

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

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

Schema coverage is 100% for the single targets parameter, and the description's 'Maximum 10 targets' merely restates the schema's 'Max 10.' No additional syntax or format meaning is added, so the baseline 3 applies.

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

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

States a specific verb (investigate), resource (multiple targets), and mode (parallel, full OSINT tool chain), which cleanly separates it from the single-target search_* and graph_* siblings. An agent can tell this is the batch orchestrator without opening the schema.

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

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

The 'Maximum 10 targets' constraint implies batch usage, but the description never states when to prefer this over the granular search_* siblings or when not to use it (e.g., single-target cases). Usage is inferable but not explicit.

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

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

With no annotations, the description carries the full burden and does well: it discloses the auth requirement (ABUSEIPDB_API_KEY env var), the external call and its footprint ('[passive] One request to api.abuseipdb.com'), and a behavioral quirk (warning emitted when score exceeds 50%). It stops short of error/rate-limit behavior or what happens on an unknown IP.

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

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

Three tight sentences, front-loaded with the verb and source, then return values, then auth/footprint caveats. Nothing is padding; the bracketed tags are terse and information-dense.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description correctly enumerates the returned fields and the warning threshold, and it covers the credential requirement and request footprint. Remaining gaps are minor (error cases, rate limits, IP format) for a single-parameter read-only lookup.

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

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

Schema description coverage is only 50% (json_output documented, ip bare), so the description must compensate and largely does not. It never states the expected IP format (IPv4/IPv6/CIDR) or what json_output changes beyond the schema's own one-liner. 'Check an IP address' only weakly maps to the ip parameter.

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

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

States a specific verb and resource ('Check an IP address') plus the exact data source ('AbuseIPDB v2 API for abuse reputation'), which is what separates it from the many other IP-oriented siblings (search_ip, search_virustotal, search_shodan, search_censys). An agent can tell which enrichment source it is getting without opening the schema.

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

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

Usage is implied by the described return values (abuse score, reports, country, ISP), so an agent can infer this is the abuse-reputation lookup. However, it never states when to prefer this over search_virustotal or search_ip, nor any exclusions or prerequisites beyond the env var. The '[passive]' tag hints at OPSEC suitability but does not define a selection rule.

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

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

With no annotations, the description carries the full burden and does add real behavioral context: it discloses the HIBP_API_KEY env var requirement, flags the operation as '[passive]', and notes it makes one request to haveibeenpwned.com. It stops short of describing error handling for unknown addresses or rate-limit behavior, but the auth and opsec disclosures are meaningful.

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

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

Three short fragments, front-loaded with the core purpose, then implementation constraints. Every clause earns its place; the bracketed '[passive]' and provider note are terse but load-bearing. Slightly telegraphic but efficient.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and no annotations, so the description should say more about what a result looks like — breach names, counts, or a bare boolean — and about behavior on a miss. The auth and network context is covered, but the return shape is left entirely unspecified.

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

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

Schema coverage is 50%: json_output is documented in the schema while email is bare. The description implies the email is the lookup key but adds no format or validation guidance, and says nothing about json_output. Adequate baseline, not compensating for the gap.

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

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

States a specific verb and resource ('Check if an email appears in data breaches') and names the data source (HaveIBeenPwned), which cleanly separates it from siblings like search_paste or search_ip. An agent can tell immediately this is an email-breach lookup, not a generic search.

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

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

The purpose implies when it applies (you have an email and want breach exposure), but there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as search_paste or investigate_multi for broader email pivoting. Usage is inferable rather than stated.

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

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

With no annotations, the description carries the full burden and does supply real behavioral context: it names the required credentials (CENSYS_API_ID and CENSYS_SECRET env vars), declares the operation passive ('[passive] ... returns data Censys already holds'), and thus signals a non-invasive read against cached third-party data. It omits rate limits, pagination behavior, and error/failure modes for missing credentials.

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

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

Four dense, front-loaded fragments using arrow notation carry purpose, per-input outputs, auth requirements, and the passive caveat with zero filler. Each sentence earns its place.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description still tells the agent the input types, the returned fields, and the credential prerequisite, which is enough to invoke it correctly. It stops short of pagination/rate-limit/completeness caveats, which would be needed for a fully autonomous call.

Complex tools with many parameters or behaviors need more documentation. Simple 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 50% (the required 'target' parameter has no schema description), so the description must compensate — and it does: the 'IP address →' and 'Domain →' clauses establish that 'target' accepts an IP or domain and what each yields. The json_output flag is already documented in the schema, so no extra credit there.

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

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

States a specific verb (Search) and resource (Censys internet-facing infrastructure data), then enumerates exactly what is returned per input type ('IP address → open ports, services, ASN, country'; 'Domain → certificate history, SANs, issuer, first/last seen'). This is well above a generic 'search' description. It does not, however, distinguish itself from the sibling search_shodan, which likely covers overlapping internet-facing infrastructure data.

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

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

Usage is implied by the returned-field breakdowns (use it when you have an IP or domain and want infrastructure/certificate data) and by the '[passive]' tag. There is no explicit when-to-use/when-not statement and no pointer to alternatives like search_shodan, so the agent must infer the routing decision.

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

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

With no annotations, the description carries the full burden and does it well: it discloses that no external API or credentials are needed, that lookups go through the resolver so the target sees the resolver rather than the caller, and that DKIM selector probing is conditional on active tools. It stops short of rate-limit or failure behavior, but the operational profile is unusually well communicated.

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

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

Four tight sentences, front-loaded with the enumeration scope and then the email-security value, followed by the passive-mode caveat. The bracketed active-tools note is dense but earns its place; nothing is redundant.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read-only lookup with no output schema and no annotations, the description covers what is enumerated, the specific misconfigurations it detects, and the passive/probing behavior. Only the shape of returned findings and the domain-parameter expectations are left implicit.

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

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

Two parameters at 50% coverage: json_output is documented in the schema while domain is not. The description implies a domain target and JSON result framing but adds no syntax, TLD, or selector-format detail beyond the schema, so it neither compensates for nor improves on the structured fields.

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

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

The description names a specific verb (enumerate) and resource (DNS records), then enumerates the exact record types it returns (A, AAAA, MX, NS, TXT, CNAME, SOA) and adds the email-security angle. This is unambiguous and clearly distinct from the IP/WHOIS/RDAP siblings.

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

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

Usage is implied by the enumeration scope and the note that DKIM selector probes only run with active tools enabled, but there is no explicit guidance on when to reach for this versus search_whois, search_rdap, or search_ip. The agent must infer when DNS enumeration is the right first step.

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

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

With no annotations, the description carries the full load and does so well: it flags billable API calls, names the required env vars (BRIGHTDATA_API_KEY, BRIGHTDATA_SERP_ZONE), and discloses that the target leaves the boundary to Google/Bright Data via the [passive] tag. It stops short of rate limits, failure modes, or what happens when the default dork set is insufficient.

Agents need to know what a tool does to the 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 dense sentences with no filler: action and return shape first, cost/credential constraints second, data-flow disclosure last. Every clause earns its place.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations and no output schema, the description does the heavy lifting — cost model, credentials, external data flow, and return fields are all covered. The remaining hole is the meaning/format of the required 'target' parameter, which leaves an agent slightly under-informed before calling.

Complex tools with many parameters or behaviors need more documentation. Simple 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 only 50%, and the undocumented parameter is the single required one — 'target' — whose expected format (domain, IP, email, query string) is never stated, only mentioned obliquely as 'for a target.' The description adds nothing to 'json_output' beyond the schema, so it fails to compensate for the coverage gap.

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

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

The description names a specific verb and resource (execute Google dork queries) plus the data source (Bright Data SERP API) and return shape (title, URL, snippet), so the agent knows exactly what happens. It implicitly separates itself from the sibling generate_dorks by emphasizing 'live,' but never names or contrasts that sibling explicitly, which keeps it short of a 5.

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

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

It discloses that up to 5 dorks run by default and that each is billable, which implies a cost-sensitive use context, but there is no explicit when-to-use versus generate_dorks (does the agent generate dorks first, or not?) and no prerequisite or exclusion guidance. Usage must be inferred.

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

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

With no annotations, the description carries the full burden and does disclose key behaviors: it is passive, requires BRIGHTDATA_API_KEY and BRIGHTDATA_SERP_ZONE, is capped at up to 3 Google queries, and warns that the target is sent to external services. It falls short of 5 only by not covering failure modes, error handling, or how partial results are surfaced.

Agents need to know what a tool does to the 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 core purpose and output are front-loaded, and the bracketed [passive] and env-var/billing details are dense but each earns its place. Slightly information-heavy for a single sentence, but not padded.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description correctly explains what comes back (structured SERP results plus graph nodes/edges), and with no annotations it covers auth, cost, and passivity. It is nearly complete; only the 'target' semantics and error behavior could be made more explicit.

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

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

The schema leaves 'target' entirely undescribed, and the description compensates by enumerating accepted entity types (email, username, domain, phone, full name). It also ties max_queries' 'up to 3' to actual Google query behavior, though json_output is not addressed. This adds real meaning beyond the 67% schema coverage.

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

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

States a specific verb and resource ('Collect a target's public search-engine footprint via the Bright Data SERP API') and details entity-type detection plus SERP and graph-node output. It is clearly distinguishable in substance, but never names or contrasts against the closely related siblings (search_dorks_live, generate_dorks), so it stops short of full sibling differentiation.

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

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

Usage is only implied by the purpose ('to footprint a target'). There is no explicit when-to-use, no when-not-to-use, and no routing to the adjacent tools (search_dorks_live, generate_dorks) that also issue Google queries, leaving the agent to infer which tool fits.

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

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

With no annotations provided, the description carries the full burden and does so well: it discloses that the tool downloads GDELT's public feed and filters locally, that the search term never leaves the machine, and that the accessible window grows as older articles load. It also documents return format (text summary + GeoJSON FeatureCollection).

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

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

Front-loaded with the core purpose, return value, and freshness caveat before the passive/privacy note. Slightly dense and the bracketed '[passive]' tag interrupts the flow, but every sentence contributes distinct information.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description explains the return payload (text summary plus GeoJSON FeatureCollection) and the coverage window caveat. For a 5-parameter search tool with no annotations, nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics beyond the schema: the bbox is optional scoping and the interplay of query "*" with a bounding box ('lists everything inside it'). It does not add new syntax for timespan or maxpoints, so it stays just above 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?

Names a specific verb and resource ('Search recent, geolocated worldwide news from GDELT's 15-minute article feed'), states the matching semantics (headlines/URLs matched against the query), and the return shape. This is unmistakably distinct from the sibling search_shodan/search_rdap/search_dns tools.

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

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

Gives clear context for use (no API key, optional bbox scoping, query "*" lists everything inside the box) and an important operational caveat about the first call covering only the last 15 minutes while older articles load. It does not explicitly name when to choose a different sibling tool, but with such disparate siblings the trigger condition is effectively self-evident.

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

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

With no annotations, the description carries the full burden and does well: it discloses rate-limit behavior, the passive nature of the requests, and the exact return shape for both query modes. It stops short of explicitly confirming read-only/side-effect-free operation or error/pagination behavior, keeping it from a 5.

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

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

Four sentences, each carrying distinct information: purpose, branching return behavior, rate-limit option, and request profile. The purpose is front-loaded and there is no filler.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description adequately explains return values for both query modes, rate limits, and passive request behavior. It is nearly complete for a 2-parameter search tool, though minor details like error handling or json_output interaction are left implicit.

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

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

Schema coverage is 50%, with json_output documented in the schema but query left bare. The description compensates by explaining exactly what values the query parameter accepts (username, email, keyword) and how results differ per type, adding meaningful semantics beyond the schema.

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

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

States a specific verb (Search) and resource (GitHub) plus the accepted query types (username, email, keyword). It does not explicitly contrast itself with any of the many sibling search_* tools, so it falls short of a 5 despite being immediately understandable.

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

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

Describes what each query type returns and mentions the optional token for rate limits. However, it gives no guidance on when to choose this tool over sibling searches like search_dorks_live or search_paste, leaving selection to inference.

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

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

With no annotations, the description must carry the full behavioral burden, and it does disclose some useful traits: the operation is passive and makes exactly one external request to ipinfo.io. It omits auth/API-key requirements, rate limits, failure behavior, and the shape of the returned data.

Agents need to know what a tool does to the 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 tight and front-loaded: purpose first, then behavioral tags. The ipinfo.io source is mentioned twice (once as source, once as request target), a slight redundancy, but the second mention conveys request-count information.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations and no output schema, the description should do more work. It covers the passive/single-request profile but leaves return fields, auth needs, and error handling unexplained, which is a meaningful gap given the absent structured metadata.

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

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

Schema coverage is only 50% and the description adds no parameter meaning at all. The 'ip' parameter is self-evident as a string, and json_output is documented in the schema, but the description does nothing to compensate for the undocumented half.

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

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

States a specific verb (retrieve) plus resource (geolocation and ASN data for an IP) and names the data source (ipinfo.io). This clearly distinguishes the tool's function, though it does not differentiate itself from the close sibling search_ip2location, which likely covers similar geolocation data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 [passive] tag implies a non-intrusive reconnaissance context and 'One request to ipinfo.io' hints at cost, giving implied usage guidance. However, no explicit when-to-use or when-not-to-use guidance is provided relative to alternatives like search_ip2location, search_abuseipdb, or search_whois.

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

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

With no annotations, the description carries the full burden and does reasonably well: it discloses the API-key auth requirement (IP2LOCATION_API_KEY), characterizes the operation as passive, and quantifies network footprint ('one request'). It omits failure behavior (e.g., missing key) and response shape specifics, but the auth and passivity disclosures are concrete value beyond the schema.

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

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

Front-loaded with the capability and return fields, then terse operational notes (env var, passive, one request). Every fragment carries some signal, though the 'Sponsored integration' note is tangential to invocation.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description must describe returns – and it does, listing geolocation, ISP, ASN, and threat-category flags. Auth, passivity, and request count are also covered. The main gap is parameter format and error handling for a two-parameter 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 only 50%:_output is documented in the schema but ip (the sole required parameter, format unspecified) is not. The description says nothing about the ip parameter's expected format or how json_output affects the result, so it fails to compensate for the coverage gap.

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

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

States a specific verb+resource (IP intelligence lookup via IP2Location) and enumerates exactly what it returns: geolocation, ISP, ASN, VPN/proxy/Tor/datacenter detection. This distinguishes it from generic siblings like search_ip or search_whois by output content. However, it never names an alternative tool or states the condition that selects it over those siblings.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is mentioned despite heavy sibling overlap (search_abuseipdb, search_virustotal, search_censys, search_ip). The '[passive]' tag hints at a non-intrusive lookup style, but the agent must infer the selection context on its own.

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

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

With no annotations, the description carries the full burden. It adds real context: the '[passive]' collection tag and 'One request to psbdmp.ws' implying a cheap, low-noise external lookup. It still omits auth requirements, rate limits, failure modes, and result shape.

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

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

Two short, front-loaded sentences with the action and scope up front. Minor redundancy: 'psbdmp.ws' appears in both sentences, so one sentence does not fully earn its place.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema and no annotations, so the description must cover return values and behavior; it does not say what a hit looks like (paste IDs, dates, counts) or how results are ranked. For a simple 2-param read tool this is adequate but incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple 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 only 50%: json_output is documented, but 'query' has no schema description. The description compensates by stating the query is an email or username, which is meaningful. It does not cover query syntax, matching behavior, or result format.

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

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

Names a specific verb (Search), a specific resource (Pastebin dumps), the target entities (email or username), and the upstream source (psbdmp.ws). It is distinguishable from siblings by resource, but it never explicitly contrasts itself with adjacent tools like search_breach or search_dorks_live.

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

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

No when-to-use, when-not, or alternative routing is provided. The 'email or username' phrasing implies the investigative scenario, but an agent gets no guidance on choosing this over the many other search_* siblings.

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

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

With no annotations, the description carries the full burden and does useful work: it discloses that registrant contacts are redacted by policy, that no API key is required, and (via '[passive]' plus the query-source note) that it contacts IANA/the registry rather than the target. It omits rate limits and failure behavior, so not a 5.

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

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

Front-loaded with the core purpose and returned fields, then terse supporting notes about redaction, auth, and reach. Dense but every sentence carries information; the prose could be slightly tightened but nothing is filler.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only lookup with no output schema and no annotations, the description supplies the important gaps: what fields come back, that contacts are redacted, that no key is needed, and the passive lookup source. Only the 'domain' parameter's format and any return-shape nuance are left unaddressed.

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

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

Schema coverage is only 50% – 'domain' is undocumented in the schema and the description never explains its expected format (bare domain vs. URL, TLD handling). 'json_output' is covered by the schema, so the description adds little beyond 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?

States a specific verb+resource ('Structured domain registration lookup via RDAP') and enumerates the returned fields (registrar, dates, name servers, status codes). It contrasts itself with WHOIS ('machine-readable successor'), which implicitly distinguishes it from the sibling search_whois, though it never names that tool directly.

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

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

Usage is only implied: by framing RDAP as the machine-readable successor to WHOIS, the description hints it is the preferred structured alternative, but it gives no explicit when-to-use/when-not guidance and never names search_whois as the alternative.

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

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

With no annotations, the description carries the full burden and does unusually well: it discloses the required SHODAN_API_KEY env var and, importantly, that it is [passive] — reading Shodan's existing index and requesting no new scan, which matters for operational security. It stops short of covering rate limits, quota consumption, or what happens on an invalid/empty query, so it is strong but not complete.

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

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

Four compact fragments, front-loaded with the core purpose and then the routing rule, credential requirement, and passivity note. Every clause adds information; there is no filler or restatement of the tool name.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter, annotation-free, output-schema-free tool, the description supplies the essentials an agent needs: what it queries, how the input maps to behavior, the auth requirement, and the non-intrusive nature. The main remaining gap is the shape of the returned data (host fields vs. banner results), which is only sketched rather than described.

Complex tools with many parameters or behaviors need more documentation. Simple 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 only 50%, but the description compensates well for the undocumented 'query' parameter by explaining its two input-dependent semantics (IP → host lookup, other string → keyword/service search), which is meaning the schema does not provide. json_output is already documented in the schema, so no extra credit is needed there.

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

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

States a specific verb (Query) and resource (Shodan) and immediately explains two distinct modes: IP address triggers a host lookup, any other string triggers keyword/service search. It is clear what the tool does, though it never explicitly contrasts itself with the closely related sibling search_censys, so sibling differentiation is left implicit in the product name.

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

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

The description gives useful routing guidance (use an IP for host lookup, use anything else for banner/keyword search), so the agent knows how to shape the query. However, it offers no guidance on when to pick this tool over overlapping siblings such as search_censys, search_dns, or search_ip2location, and no exclusions or prerequisites are stated.

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

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

With no annotations, the description carries the full burden and does well: it discloses the required VIRUSTOTAL_API_KEY env var, the side effect of URL submission (VirusTotal fetches the URL and exposes it to the community), and that this active mode is off by default. Rate limits and quota behavior are not mentioned, and no output/return format is described.

Agents need to know what a tool does to the 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 dense sentences, front-loaded with purpose and the input-type list, then the environment prerequisite, then the passive/active distinction. Every sentence adds information; nothing is redundant with the schema.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter lookup tool with no output schema and no annotations, the description covers auth, accepted inputs, and the important active-mode side effect. The main omission is any hint of what a result contains or how large/expensive a query can be, which matters given an external API quota.

Complex tools with many parameters or behaviors need more documentation. Simple 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 50%: json_output is documented in the schema, but target is bare. The description compensates by enumerating the accepted input types (IP, domain, URL, file hash) and noting that the type is auto-detected, so an agent knows what to pass without guessing a format prefix.

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

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

States a specific verb (check/scan) and resource (IP, domain, URL, file hash) against a named service, and the '70+ antivirus engines and threat intelligence' phrasing distinguishes it from geolocation/DNS/WHOIS siblings in the same search_* family.

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

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

Explains that input type is auto-detected and clearly separates the default passive lookup from the opt-in active URL submission mode, which is genuine when-to-use guidance. It does not, however, route the agent to alternatives like search_abuseipdb or search_shodan for overlapping IP/domain reputation needs.

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

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

With no annotations, the description carries the full burden, and '[passive] Queries the registry/registrar WHOIS server, not the target' is a genuine behavioral disclosure (no direct contact with the target, so no target-side logging). That is valuable, but it stops short of disclosing rate limits, auth requirements, or error behavior for unavailable domains.

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

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

Two terse sentences with zero filler, and the core purpose is front-loaded before the qualifier. Every clause earns its place.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and no annotations, so the description bears responsibility for return format and safety profile, yet it says nothing about output shape or whether the lookup is cached/rate-limited. The passive-mode note partially compensates, but a 2-parameter lookup tool with 50% schema coverage and no annotations warrants more.

Complex tools with many parameters or behaviors need more documentation. Simple 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 only 50% (json_output is documented in the schema, domain is not), so the description should compensate but adds no parameter detail. The domain input is largely self-evident, but the description never states expected format (bare domain vs. URL vs. IP) or whether the json_output flag can apply to batch lookups.

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

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

Specific verb ('retrieve') plus resource ('WHOIS registration data') and an explicit target ('for a domain'), so the agent knows exactly what it returns. It does not distinguish itself from the sibling search_rdap, which is the closest alternative (RDAP being the WHOIS successor), so sibling differentiation is missing.

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

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

The '[passive]' tag implies the operational context (stealth/OSINT where the target must not be contacted directly), which is useful implied guidance. However, there is no explicit statement of when to prefer this over search_rdap or the other search_* siblings, so the agent must infer the choice.

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