osint_subdomain_enumeration

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

No annotations are supplied, so the description carries the full burden. It does disclose useful behavioral facts the schema cannot: the data source (CT logs), that results include both active and historical subdomains, and a speed expectation. However, it says nothing about rate limits, authentication, pagination of results beyond the limit, or what happens for domains with no CT coverage.

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 purpose sentence is front-loaded and information-dense with no filler. The Args block is a slightly redundant docstring format that repeats the schema's default 50, but it is short and scannable rather than 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?

An output schema exists, so return-shape explanation is not required, and with only two parameters the surface area is small. The description covers what the tool does and the source of data; the only real gap is the absence of any guidance tying it to the other OSINT domain tools in the sibling set.

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 0%, so the description must compensate. It clarifies that 'domain' is the root domain (with concrete examples like target.com vs github.com) and that 'limit' caps returned subdomains at a default of 50, which adds real meaning beyond the bare 'string'/'integer' types. It leaves open whether limit truncates arbitrarily or by relevance, and whether ordering is defined.

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 opens with a specific verb+resource ('Enumerate ... subdomains for any domain') and names the mechanism (Certificate Transparency Logs) plus a speed claim under 1 second. An agent can immediately tell this is a passive subdomain discovery tool, distinct from scraping siblings. It stops short of naming how it differs from the closely related osint_domain_recon or osint_dns_audit.

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 mention of the alternatives in the sibling set (osint_domain_recon, osint_dns_audit, osint_tech_stack). The 'Subdomain Recon Tool' label implies a domain-recon context, but the agent must infer when to pick this over the other OSINT domain tools.

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