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

With no annotations, the description carries the full burden and mostly does: it names the model, discloses a prompt-refinement step by Claude that means the final prompt may differ from input, states content screening, alt-text and scoring side effects, the exact return type (base64 PNG data URI), and flat $0.25 pricing. It omits latency, rate limits, and failure/refusal behavior, and the trailing 'n=1…' fragment is truncated and inconsistent with a schema that exposes no n parameter.

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 and capability are front-loaded in the first clause, which is exactly right, and the pipeline, output and price details are dense rather than padded. The garbled trailing 'Flat $0.25; n=1…' fragment truncates mid-thought and slightly weakens the close.

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?

The description is complete on behavior, cost and return format, and no output schema exists so explaining the return value is a genuine contribution. However, for a five-parameter generative tool with zero schema descriptions and no annotations, the total absence of parameter guidance leaves a real gap 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 description coverage is 0% across five parameters, so the description must compensate and it does not: prompt, style, use_case, aspect_ratio and brand_colors are never explained or given accepted formats. Aside from the implicit 'prompt' being required and refined, an agent gets no guidance on valid values for the other four 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?

Specific verb ('Generate') plus a concrete resource ('image assets') with enumerated output types (icons, logos, social graphics, thumbnails, banners) and the underlying model (gpt-image-1). No sibling tool does image generation, so the agent can place this correctly in the catalog without further reading.

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 asset types listed and by the 'agent-ready' framing, which hints at the intended context, but there is no explicit when-to-use statement, no prerequisites (e.g. prompt quality requirements), and no routing away from alternatives such as the text-only OpenAI siblings. Adequate but leaves the agent to infer fit.

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?

No annotations are provided, so the description carries the full burden. It usefully enumerates what the caller gets back (ASN, owner, country, hosting/cloud classification, trust score), which implies a safe read-only lookup, but it never states that it is read-only, nor mentions auth needs, rate limits, or whether the trust score is a heuristic.

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?

One front-loaded sentence that names the input and the full set of outputs with no filler. 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?

For a single-parameter lookup with no output schema and no annotations, the description covers both input and the shape of the result well. It stops short of noting the read-only nature or error behavior, but nothing critical for invoking 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 description coverage is 0%, so the description must compensate for the single undocumented 'target' parameter. Saying it accepts 'an IP or domain' does exactly that by defining the accepted input types, which is meaningful added value beyond the bare string 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?

The description states a specific verb (resolve) and resource (IP/domain to ASN, network owner, country, hosting/cloud classification) plus the trust-score output, so the tool's function is unambiguous. It does not explicitly differentiate itself from close siblings like netintel_ip_geo or netintel_ip_reputation, relying on the ASN/ownership framing to do that implicitly.

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 guidance on when to pick this over netintel_ip_geo, netintel_ip_reputation, or netintel_whois_lookup, which all touch adjacent ground. Usage is only implied by the described outputs, with no conditions or exclusions 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 delivers genuinely useful behavioral context: it discloses the external dependency (HaveIBeenPwned k-anonymity API) and the privacy property that only a 5-char SHA-1 prefix leaves the caller. It omits rate limits, auth requirements, and result semantics, 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?

Two sentences, zero waste. The purpose is front-loaded and the privacy mechanism follows as immediate reassurance about how the input is handled.

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 one-parameter tool with no annotations and no output schema, the description covers what the tool does and how input is protected, but says nothing about what the result contains (breach boolean vs. occurrence count) or call limits. Adequate but with clear gaps.

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 0% for the single parameter, so the description must compensate. It implies the caller passes a plaintext password (not a pre-computed hash) and clarifies how it is processed, but adds no format, length, or encoding constraints.

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: checking whether a password appears in known breach data, plus the backing API. The resource ('password') inherently separates it from the sibling netintel_username_check, though no sibling is named explicitly.

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 explains the mechanism but gives no when-to-use guidance, no prerequisites (e.g., API key), and no exclusions or alternatives. An agent must infer the usage context entirely.

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 usefully discloses a concurrency model and a hard batch cap of 50 combinations, plus the per-domain return fields (status, registrar, expiry). It says nothing about partial-failure behavior, rate limits, auth, or what happens when the cap is exceeded.

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 and dense with no filler, but the single sentence is visibly truncated ('an entire naming…'), leaving the description structurally incomplete.

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, no-annotation, no-output-schema tool, the description covers the batch limit and return shape but leaves the names/tlds contract and error semantics for an agent to infer. Adequate, with clear gaps.

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 0%, so the description must compensate. It implies the names/tlds relationship by describing 'name/TLD combinations' and caps the total at 50, but never states that tlds is optional, what default TLD set applies, or whether the result is a cartesian product.

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 (check availability), resource (domain names across multiple TLDs), and a bulk scope ('many', 'up to 50 combinations in a single call'). The bulk framing implicitly separates it from the singular netintel_domain_availability sibling, but no sibling is named explicitly.

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 trailing clause ('so agents can scan an entire naming…') gestures at a bulk-scanning use case, but is truncated and never states when to prefer this over netintel_domain_availability or netintel_domain_vet, nor any precondition or exclusion.

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 behavioral burden and does well: it discloses escaping, line folding, timed vs all-day handling, and a deterministic UID enabling idempotent re-import — a genuinely useful behavioral trait. It falls short of explaining the return shape (ICS text vs file/link), which matters for a no-output-schema tool.

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?

A single front-loaded sentence packs the format, capabilities, and benefit efficiently with no filler. The trailing ellipsis and mid-clause truncation ('Google, Apple…') slightly blunt the finish but the core statement is tight.

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 nine-parameter tool with no annotations and no output schema, the description covers the conversion behavior well but leaves the parameter contract largely unexplained. An agent knows what it produces but not how to format most of the inputs.

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 0% across nine parameters, so the description must compensate — and it barely does. Only the all-day concept is indirectly echoed; nothing explains starts_at/ends_at formats, timezone handling, the 'url' field, or organizer/description semantics, leaving most inputs undocumented anywhere.

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 — 'Turn event fields into a valid RFC 5545 .ics calendar file' — which is unmistakable and clearly distinct from the extraction/classification siblings. The mention of timed/all-day handling and RFC 5545 formatting sharpens what the tool actually produces.

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 trailing 'so agents can publish events that import cleanly into Google, Apple…' implies the use case (publishing events), but there is no explicit when-to-use vs an alternative, and no routing guidance relative to netintel_event_extract or netintel_event_classify. Usage is inferable but not 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 behavioral burden. It does disclose the return contents (subdomains, issuers, wildcard/suspicious flags), which is genuinely useful, but says nothing about crt.sh being a slow third-party service, rate limits, or truncated/paginated results — all real operational concerns for CT log queries.

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 sentences, no filler, with the data source and scope front-loaded and the return contents in the second sentence. 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, so the description correctly picks up the job of describing returns, and it does so briefly. However, for a three-parameter tool with zero schema documentation and no annotations, it omits parameter behavior and external-service caveats, leaving meaningful gaps.

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% and the description never mentions any of the three parameters. 'Enumerate all SSL certs for a domain' loosely implies the domain parameter, but the meaning of 'limit' and especially 'include_subdomains' (which materially changes the result set) is left entirely undocumented in both description and 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 (Query), a named external source (crt.sh certificate transparency logs), and a precise scope (all SSL certs ever issued for a domain). This is clearly distinguishable from siblings like netintel_ssl_cert (reads one cert) or netintel_ssl_analyze (analyzes a live endpoint) 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.

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

There is no when-to-use guidance, no when-not-to-use, and no named alternative among the many SSL/DNS/domain siblings. The agent must infer that this tool is the subdomain-enumeration path rather than the certificate-inspection path, which is non-obvious given the crowded sibling set.

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 real behavior: zero-shot operation, the 2–20 label cardinality constraint, the underlying model, and the return shape (best-matching category with confidence and per-label scores) even though no output schema exists. It omits failure modes (what happens below 2 labels), latency/rate limits, and how behavior changes when multi_label is set.

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 dense sentences with the core mechanism front-loaded and no filler. The trailing use-case list earns its place by scoping the tool rather than padding it.

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 three-parameter tool with no annotations and no output schema, the description supplies the essentials an agent needs: what it returns, the model, and the label constraint. The one meaningful hole is multi_label semantics and the related single-vs-multi output behavior.

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 0%, so the description must compensate and it only partly does: it adds the '2–20 labels' cardinality rule that is nowhere in the schema, and 'text' is self-evident. The 'multi_label' parameter is never explained, and the phrase 'returns the best-matching category' (singular) actively muddies what multi_label=true would produce.

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 (classify text) plus the mechanism (zero-shot with 2–20 caller-supplied labels, Claude Haiku). The repeated emphasis on 'your own categories'/'your own taxonomy' functionally separates it from fixed-taxonomy siblings like netintel_sentiment, netintel_content_moderate, and netintel_event_classify.

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 concrete use cases — 'Route, tag, triage, and detect intent or topic' — which tells an agent the situations this fits. It never names an alternative tool or states when not to use it (e.g., use sentiment when labels are fixed), so it stops short of explicit routing guidance.

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 behavioral burden. It does disclose useful edge-case behavior (hosts resolving but serving nothing on 80/443 yield http_reachable:false and grade 'insufficient_data') and the presence of confidence scores, but says nothing about permissions, rate limits, or latency, leaving a meaningful gap for a network-probing tool.

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 sentences, both load-bearing: the first front-loads the capability and output fields, the second captures a genuinely non-obvious edge case. No filler or repetition 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?

With no output schema and no annotations, the description does the heavy lifting by enumerating return fields and the insufficient_data edge case, which is enough to call and interpret the tool. The missing sibling disambiguation and input-format detail keep it from a 5.

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?

There is one parameter ('domain') at 0% schema description coverage, so the description is the only source of meaning. It implies the input is a domain, but does not specify format (bare host vs. URL vs. scheme) or how subdomains are treated, adding little beyond the self-evident 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?

The description names a specific verb ('Detect') and enumerates the exact resources probed (CDN, WAF, hosting, DNS, email provider, TLS issuer, wildcard coverage, SAN count, security grade), so the agent knows precisely what comes back. It falls short of a 5 only because it never distinguishes itself from close siblings like netintel_tech_fingerprint or netintel_ssl_analyze.

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 guidance on when to pick this tool over the overlapping netintel_tech_fingerprint, netintel_ssl_analyze, netintel_dns_lookup or netintel_cert_transparency siblings, and no prerequisites or exclusions stated. The single host-with-nothing-served note is a behavior, not a routing hint.

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 it does disclose useful behavior: the model used (Claude Haiku) and the response shape (per-category severity plus an allow/flag/block recommendation). It says nothing about latency, cost/rate limits, input length limits, language coverage, or failure behavior for short/ambiguous text, which are material for an LLM-backed moderation call.

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?

A single dense sentence that front-loads the verb, the model, the categories, and the output verdict — minimal waste. It is truncated with an ellipsis, leaving the final clause incomplete, which is the only structural defect.

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 one-parameter tool with no output schema and no annotations, the description helpfully sketches the return shape (category severities + recommendation) but omits input-format expectations and any operational limits. The truncated ending leaves the reader unsure whether more guidance was intended.

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?

Only one parameter ('text') with 0% schema description coverage, so the schema alone is not self-explanatory. The description implies the input is raw text to be screened, but adds no constraints such as supported languages, max length, or whether markup should be stripped.

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 ('Moderate text content') and enumerates the exact output categories (harassment, hate, sexual content, violence, self-harm, spam) plus the overall allow/flag/block verdict, which clearly separates it from siblings like netintel_sentiment or netintel_classify. It never names an alternative tool, so it does not fully earn 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?

The trailing clause 'so agents can screen user-generated…' implies the intended context (moderating UGC before display), which is genuine implied-usage guidance. However there are no explicit when-to-use/when-not conditions, no named alternatives, and the sentence is cut off mid-thought.

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 it does add real behavior: auto-detection of unit category and handling of US/imperial ambiguity. However it says nothing about error behavior for unsupported or mismatched units, precision/rounding, or what the `system` and `base` parameters change in behavior.

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 action and an efficient list of supported categories in a single sentence. The trailing ellipsis suggests the text is truncated, which is the only structural blemish.

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 5-parameter tool with zero schema descriptions, no annotations, and no output schema, the description is too thin. It omits any explanation of the non-obvious `base` and `system` parameters and gives no indication of return shape or failure modes.

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% across 5 parameters, and the description never explains `value`, `from`, `to`, `base`, or `system`. The auto-detect claim loosely gestures at `system`/`base` but gives no syntax, allowed values, or defaults, so the description does not compensate for the schema 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 ('Convert any physical measurement to another') and enumerates the supported categories, which separates it from the money-oriented siblings like netintel_currency_exchange and netintel_crypto_price. An agent can tell what this tool does 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 only implied by the category list ('length, mass, volume, temperature...'), which lets an agent infer the domain but gives no explicit when-to-use or when-not-to-use guidance. No alternative tool (e.g. currency conversion) is named or excluded.

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?

No annotations exist, so the description carries the full burden. It does disclose the return content (explanation + 5 run times), which is genuinely useful behavior, but it says nothing about timezone basis for the computed runs, how invalid expressions are handled, or accepted cron dialects — the two traits an agent most needs to know before trusting the output.

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?

A single front-loaded sentence naming all three outputs with zero filler. Nothing to trim and nothing buried.

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 one-parameter utility with no output schema, the description adequately frames what comes back, but the omission of timezone semantics and invalid-input behavior leaves real gaps for a tool whose entire value is time computation.

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?

One required parameter with 0% schema description coverage, so the description must compensate. 'Parse a cron expression' does identify what the parameter is, but gives no format guidance (5-field vs 6-field, named aliases like @daily, MON-SUN) and no example.

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 (parse a cron expression) plus two concrete derived outputs: a plain-English explanation and the next 5 run times. No sibling tool in the list does cron work, so it is trivially distinguishable.

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 purpose — an agent knows to call it when it has a cron expression — but the description offers no explicit when-to-use trigger, no precondition (e.g. expression must be valid/standard format), and no note about re-interpreting results via a sibling.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses data sources (Coinbase Exchange, CoinGecko), quote currencies, and a truncated '60s…' hint about refresh/cache timing, but omits authentication needs, rate limits, error behavior, and the meaning of the '60s' interval. Partial behavioral context only.

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 a single dense sentence that front-loads the core purpose and data fields efficiently. However, the trailing '60s…' is truncated and incomplete, which slightly hurts structure and leaves a dangling detail.

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 does a good job listing the returned fields and their sources. It remains incomplete regarding parameter formats, usage routing, and the truncated '60s…' rate/cache behavior, but covers the essential return value landscape better than most.

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 explains the 'vs' parameter by listing USD, EUR, and GBP, and implies the 'symbol' parameter through '~50 top assets', but does not specify symbol format (e.g., BTC vs bitcoin) or whether 'vs' has a default. It adds partial meaning beyond the empty 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?

The description names a specific resource (live crypto market data for ~50 top assets) and explicitly lists the combined data fields (spot price, 24h OHLCV, change, market cap, rank, supply) and sources (Coinbase Exchange, CoinGecko). This distinguishes it from sibling tools like netintel_crypto_price or netintel_crypto_ohlc that provide narrower single-source 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 description provides no explicit when-to-use guidance, no when-not-to-use conditions, and does not name alternatives such as netintel_crypto_price or netintel_market_snapshot. Usage is only implied by the data content.

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 it does disclose meaningful traits: data provenance (Coinbase Exchange with Kraken fallback), no API key required, and a hard cap of 300 candles. It says nothing about rate limits, failure behavior when both sources miss, or the shape of the returned data, leaving real gaps for a data-fetch tool.

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?

Dense and front-loaded — the primary purpose and its limits come first, with the alternate mode last. It is appropriately short for the information conveyed, though the final clause trails off ('for…'), leaving an unfinished thought that slightly hurts the structure.

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 is the only source of truth for a 5-param tool with 0% schema coverage. It covers purpose, sources, limits, and two modes but is truncated mid-sentence and never resolves the remaining parameters, so an agent still cannot call it confidently.

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% across 5 params, so the description must compensate. It supplies the date format (YYYY-MM-DD), the interval values (hourly/daily), the candle ceiling, and the asset scope for symbol, but leaves 'vs' (quote currency) and 'days' completely unexplained. Partial compensation, not full.

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: 'Historical OHLC candles for any major crypto asset,' with scope qualifiers (hourly or daily, up to 300 candles) and a named second mode. It is clearly distinguishable from spot-price tools like netintel_crypto_price in substance, but it never names a sibling to route against, so it stops 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?

Gives operational guidance for the primary mode (interval granularity, candle cap) and shows the alternate invocation ('pass date=YYYY-MM-DD'), which is implied when-to-use. However it never says when to prefer this over netintel_crypto_price / netintel_crypto_market, nor any exclusions or prerequisites, so guidance remains implied rather than 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 disclose meaningful behavior: Coinbase primary with Kraken and CoinGecko fallback, no API key required, cache age per asset, and that 24h change is only present 'when the source provides it'. This is solid operational context, though rate limits and error behavior are absent.

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 is front-loaded in the opening clause, followed by source, pricing, and return-field details in a compact em-dash structure. Mostly dense with little waste, though the run-on length slightly hurts scannability.

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 tool with no annotations and no output schema, the description adequately covers return fields, data sources, fallback, and caching. It still omits parameter formats, defaults for 'vs', and rate/error behavior, so it is adequate but not complete.

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 0% for both parameters, so the description must compensate and partially does: it maps the accepted quote currencies to 'vs' (USD, EUR, GBP) and illustrates 'symbols' with BTC, ETH, SOL plus a 25-coin cap. It never specifies the actual input format (comma-separated string? array?), leaving a real 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 states a specific verb and resource — live cryptocurrency spot prices — with concrete scope (up to 25 coins per call, BTC/ETH/SOL examples, USD/EUR/GBP). It clearly implies batch spot-price retrieval as distinct from single-asset or OHLC tools, though it never names a sibling such as netintel_crypto_ohlc or netintel_crypto_market explicitly.

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 rather than stated: 'up to 25 coins in one call' and 'no API key, one flat price' signal a fast batch spot-price lookup with no auth friction. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g. crypto_ohlc for historical candles), so the agent must infer the routing.

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 behavioral burden, and it discloses almost nothing: not whether the rate is mid-market or bid/ask, not the base/quote convention, not what happens on unsupported currency codes or future dates, and not any auth or rate-limit behavior. 'Real-time or historical' is the only real behavioral signal.

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, front-loaded with the core capability and followed by the one actionable parameter hint. No filler or redundancy.

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?

A four-parameter tool with no annotations and no output schema needs the description to explain inputs, defaults, and return shape. The description omits amount handling, currency-code format, error behavior, and — critically — the boundary against the batch and history siblings, leaving the agent to guess which of the three to 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 description coverage is 0%, so the description must compensate, and it only partially does: it gives the date format (YYYY-MM-DD) but says nothing about 'amount' (optionality, default of 1?), or whether 'from'/'to' expect ISO 4217 codes, symbols, or names. Two of four parameters are effectively undocumented.

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 (convert) and resource (currencies) with a scope detail (32 currencies, real-time or historical). It does not, however, distinguish itself from the sibling tools netintel_currency_exchange_batch and netintel_currency_exchange_history, and the historical-lookup sentence actively blurs the line with the latter.

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 only usage cue is 'pass a date for historical lookup,' which is a parameter instruction rather than guidance on when to choose this tool over currency_exchange_history or currency_exchange_batch. No exclusions, no prerequisites, no statement of when the real-time path is appropriate.

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 present the description carries the full burden, and it does disclose meaningful behavioral facts: the two rate sources, no API key requirement, and the per-target response fields (rate, converted amount, rate date, source). It omits error behavior for unknown/unsupported currency codes and any rate limits or caching, and the text is visibly truncated mid-sentence ('The…').

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?

Dense, front-loaded, and largely waste-free—the conversion scope leads and sources follow. The trailing truncated fragment ('The…') is a structural defect that leaves the sentence unfinished.

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 handles returns by enumerating rate, converted amount, rate date, and source. What remains missing is the 'to' list encoding and the 'amount' default, both of which an agent needs to build a valid 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 description coverage is 0%, so the description must compensate. It conveys that 'from' is the single base and 'to' is a set of up to 30 targets, but it never states the list format for 'to' (comma-separated? repeated codes?) despite the schema typing it as a bare string, nor whether 'amount' defaults to 1 when omitted. Partial compensation only.

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 (convert one base currency to up to 30 targets), gives the scope bound, names the data sources (ECB reference rates + Coinbase spot), and says no API key is needed. An agent can distinguish this from the singular netintel_currency_exchange sibling purely from the description.

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 phrase 'one base currency to up to 30 targets in a single call' gives a clear usage context: pick this when many conversions share a base. It does not explicitly name netintel_currency_exchange or netintel_currency_exchange_history as the alternatives, nor state when not to use the batch form.

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 context: data sources (ECB, Coinbase), 'no API key' auth, and the min/max/average/change stats returned. It stops short of rate limits, error behavior for invalid pairs, or return structure, leaving meaningful behavioral gaps.

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?

Dense and front-loaded: purpose, sources, stats, and auth come before the date-mode guidance, with no filler. The trailing ellipsis suggests it is truncated, but the visible text is efficiently structured.

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 5-param tool with no annotations, no output schema, and 0% schema coverage, the description covers provenance, stats, and date modes but omits the currency-pair format and any return-shape detail. Adequate but not complete for the structured-data void it must fill.

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% across 5 params, so the description must compensate. It clarifies start/end/days (with a default of 30) and implies from/to are the currency pair, but it never states the required currency-code format, leaving the two required params under-specified.

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 ('Daily historical exchange-rate series for any currency pair') and even names the data provenance (ECB fiat, Coinbase crypto) and computed stats. It is clearly distinguishable from the spot-rate sibling netintel_currency_exchange by the 'history' framing, though it never names that sibling explicitly.

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 'historical... series' versus the live-rate siblings, and it explains the date-selection modes ('Pass start/end dates or a days lookback (default 30)'). However there is no explicit when-to-use/when-not statement and no named alternative, so the agent must infer the boundary with netintel_currency_exchange.

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 it does disclose real behavior: eight record types in a single call, SPF/DMARC/DKIM parsing, and A-record cross-checking against three named resolvers. It omits rate limits, failure modes, and whether the extra parsing always runs, so the disclosure is partial.

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 sentences, front-loaded with the core verb and resource, with the enumeration and enrichment features following. Dense but essentially waste-free; only the long record-type list and acronym stack slow the read slightly.

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 single-parameter tool with no annotations and no output schema, the description adequately explains what it returns conceptually, but it leaves the input format, sibling routing, and any return-shape expectations unaddressed. Adequate, not complete.

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 0% and there is one undocumented parameter. 'For any domain' loosely signals the input shape, but the description never states whether a bare domain, subdomain, or URL is accepted, and listing PTR records is ambiguous because reverse lookups normally require an IP, not a domain.

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 ('DNS lookup for any domain') and enumerates the exact record types resolved (A, AAAA, MX, TXT, NS, CNAME, SOA, PTR), so the agent knows precisely what the call covers. It stops short of distinguishing itself from close siblings like netintel_dns_propagation or netintel_dnssec_validate.

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 statement of when to use this tool versus the many adjacent siblings, and no exclusions. The claimed cross-resolver propagation check actively overlaps with netintel_dns_propagation without clarifying the division of labor, which could misroute an agent.

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?

No annotations are present, and there is no output schema, so the description carries the full burden. It usefully discloses the return shape (per-resolver results, propagation percentage, divergence flags) and implies a read-only multi-resolver fan-out, but says nothing about latency, timeouts, rate limits, or what a 'divergent' result means operationally.

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 tight sentences, front-loaded with the action and scope, followed by the return payload. No filler, no restatement of the name, 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 right thing by summarizing the response, which largely covers the return-value gap. But leaving record_type undefined and never contrasting with netintel_dns_lookup means an agent still has unanswered questions before calling it correctly.

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% for two parameters, so the description must compensate and does not. 'Domain' is self-evident, but record_type is never mentioned in the description and no allowed values (A, AAAA, MX, TXT, etc.) are given anywhere, leaving a required dimension of the call undocumented.

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 DNS propagation') and adds concrete scope ('across 10 global resolvers simultaneously'), which is more informative than the bare name. However, it never distinguishes itself from the very close sibling netintel_dns_lookup, so an agent cannot tell from the description alone which of the two to pick.

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 implies the use case (propagation verification after a DNS change) but gives no explicit when-to-use rule, no when-not-to-use, and no mention of the adjacent alternative netintel_dns_lookup or netintel_dnssec_validate. Routing between the DNS family of siblings is left entirely 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?

No annotations are provided, so the description carries the full burden. It does not disclose whether the tool is read-only, requires network access, may be rate limited, has latency implications from multi-record resolution, or what happens on unsigned domains. The mention of 'chain-of-trust assessment' hints at scope but provides no operational behavior detail.

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 tight sentences, front-loaded with the purpose and followed by the specific checks performed. No filler. Loses a point because it does not address the required input at all, leaving the agent without essential framing.

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?

A validation tool with no annotations, no output schema, and no parameter documentation. The description covers WHAT is checked but not how results are returned, the meaning of a failed validation, or acceptable inputs. For a tool whose output is a 'chain-of-trust assessment', the absence of any return-format guidance is a meaningful gap.

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?

One parameter (domain) with 0% schema description coverage and no description text explaining it. The schema field has no description, so the definition must compensate but does not mention the parameter's expected format, whether it accepts subdomains, or whether it accepts a list. A baseline 4 does not apply because the single param is entirely undocumented and the description ignores it.

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 (Validate) and resource (DNSSEC configuration), then enumerates exactly what is checked (DS records, DNSKEY, RRSIG, NSEC/NSEC3). This distinguishes it clearly from sibling DNS tools like netintel_dns_lookup, netintel_dns_propagation, and netintel_domain_vet.

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?

Implies usage through the stated purpose (validating DNSSEC specifically), which is enough to distinguish it from the plain DNS lookup sibling. However, it never states when-not to use it, no prerequisites (e.g., whether the domain must be registered or have a parent zone), and does not name alternatives.

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 it does disclose meaningful behavior: the output is an aggregated 0-100 score framed as a 'safe to do business with this domain?' verdict, and it names the underlying signals. However it says nothing about cost/latency (composite calls are usually heavier than single-signal calls), caching, failure behavior when a component signal is unavailable, or how the score should be interpreted.

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?

One front-loaded sentence that leads with the deliverable ('Composite 0-100 trust/risk score') and then justifies it with the signal list; no filler. The text is visibly truncated mid-clause ('verdict with…'), which prevents a higher mark.

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 the interface — it names what goes in at a high level and what the headline result is, but omits the composition details of the returned score (sub-scores, thresholds, verdict bands) and any guidance for interpreting a mid-range score. Adequate but with clear gaps.

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% — the single 'domain' parameter has no description — and the visible description says nothing about the expected format (bare hostname vs. URL, www/subdomain handling, IDN/punycode). For a low-coverage schema the description is expected to compensate, and it does not.

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: a composite 0-100 trust/risk score for a domain, and enumerates the signal sources (domain age, SSL/TLS, DNS health, email auth, IP reputation, cert transparency). The phrase 'in one call' distinguishes it implicitly from the atomic siblings (netintel_domain_age, netintel_ssl_analyze, netintel_email_auth), but it never names or contrasts the competing aggregate siblings (netintel_domain_vet, netintel_domain_report, netintel_domain_appraise), so differentiation is inferential rather than explicit.

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?

'In one call' hints that this replaces multiple single-signal lookups, which implies when to reach for it, but there is no explicit when-to-use/when-not statement and no routing between it and the many other domain-rating siblings. Usage is implied, not 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?

No annotations exist, so the description carries the full behavioral burden. It does disclose concrete output semantics (creation date, age in years, first Wayback capture, snapshot count, maturity signal), which is useful given there is no output schema, but it says nothing about missing/unregistered domains, error behavior, rate limits, or data sources.

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?

It is front-loaded with the core action, which is good, but the long em-dash enumeration of return values is verbose and the text is visibly truncated mid-sentence ('and…'), leaving the structure incomplete rather than tight.

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?

Because there is no output schema, enumerating return fields is genuinely valuable and partially completes the picture. However, the truncation, missing parameter format, and total absence of usage routing or failure-mode behavior leave it short of what a 1-param, annotation-free, output-schema-less tool needs.

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 single 'domain' parameter has 0% schema description coverage, and the description adds no meaning about expected format (bare domain vs URL, scheme handling, subdomain behavior). With one undocumented required parameter, the description should compensate but does not.

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 gives a specific verb and resource ('Determine a domain's age from registration data and archival history') and enumerates the exact outputs. It is clear what the tool does, but it never differentiates itself from heavily overlapping siblings such as netintel_whois_lookup, netintel_wayback_lookup, or netintel_domain_vet.

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 only guidance is the trailing rationale 'so agents can assess domain trustworthiness', which implies a purpose but names no conditions, prerequisites, or alternatives. With dozens of near-duplicate domain tools among the siblings, the absence of any explicit when-to-use routing is a real gap.

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 behavioral burden. It discloses that valuation uses transparent heuristics and returns a value tier plus a 0-100 quality score, which is useful. However, it does not state auth requirements, rate limits, side effects, or whether the operation is purely read-only, and the truncated ending leaves the disclosure incomplete.

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 content is front-loaded with the main verb and resource, and it avoids unnecessary padding. However, the sentence is truncated with a dangling 'so…', making it structurally incomplete and reducing confidence in the intended full message.

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 one-parameter tool with no output schema and no annotations, the description should be self-sufficient. It explains the heuristic basis and return shape in part, but the truncation, lack of parameter format detail, and absence of sibling guidance leave meaningful gaps.

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% and the single 'domain' parameter is undocumented in the schema. The description mentions 'domain name' but adds no format guidance, examples, or constraints such as whether it accepts bare domains, URLs, or subdomains. It does not compensate for the missing schema documentation.

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: 'Estimate the market value tier of a domain name.' It also lists the heuristics used and the outputs, making the purpose clear without opening the schema. It does not explicitly differentiate itself from sibling tools like netintel_tld_price or netintel_domain_vet, but the valuation focus is distinct enough.

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 guidance, no mention of alternatives, and no conditions or exclusions. The description implies a domain valuation context but does not help an agent decide between this tool and related siblings such as netintel_domain_age, netintel_domain_report, or netintel_tld_price.

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 it does disclose useful behavior: the lookup method (RDAP and DNS) and the returned fields (availability status, registrar, expiry per TLD). It is silent, however, on rate limits, partial-failure behavior across the 10 TLDs, and whether results are live or cached.

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 tight sentences with the capability front-loaded and the return payload second; nothing is wasted. It is efficient, though it spends no words on the input ambiguity that most needs resolving.

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 useful work by enumerating the return fields. The remaining hole is the input contract and error/partial-result behavior for a multi-TLD sweep, which an agent cannot infer from the schema.

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% for the single 'domain' parameter, so the description must compensate and does not. It never clarifies the expected input format — a registrable name only versus a full domain with TLD — which is the single most consequential ambiguity given the tool iterates over 10 TLDs itself.

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+resource ('Check if a domain is available for registration') and adds distinguishing scope ('across 10 TLDs simultaneously using RDAP and DNS'). An agent can tell this apart from netintel_domain_vet, netintel_whois_lookup, and netintel_domain_age by outcome, though no sibling is named explicitly.

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 when-to-use guidance, no statement of prerequisites, and no routing to alternatives such as netintel_domain_vet (reputation) or netintel_tld_price (pricing) for related questions. Usage is only implied by the verb 'check ... for registration'.

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 behavioral burden. It usefully discloses execution behavior — the three lookups run 'concurrently' and it handles failures 'with graceful…' (presumably degradation/fallback), which is meaningful for a fan-out aggregator. However, it omits auth requirements, rate limits, latency expectations, and how partial results are surfaced, and the text is truncated mid-disclosure.

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?

A single dense sentence with the value proposition front-loaded and zero filler. It is slightly penalized because the text appears truncated ('with graceful…'), leaving an unfinished clause rather than a complete thought.

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 multi-source aggregator with no output schema and no annotations, the description should say more about what the 'acquisition brief' contains and how the heuristic appraisal and partial-failure handling work. It conveys the concept adequately but leaves the agent guessing at return shape and failure semantics.

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% and the description says nothing about the single 'domain' parameter — no expected format (bare domain vs URL vs with TLD), normalization behavior, or validation. The name is largely self-evident, but the description adds no meaning 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?

The description states a concrete composite action: combining domain availability, heuristic value appraisal, and TLD pricing into a single acquisition brief. This implicitly routes the agent away from the single-purpose siblings (netintel_domain_availability, netintel_domain_appraise, netintel_tld_price) toward the all-in-one call. It is clear but does not name those siblings explicitly.

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 rather than stated: 'One call combines...' suggests this is preferred when the agent wants availability, value, and pricing together, versus making three separate calls. There is no explicit when-to-use/when-not guidance and no mention of the tradeoff (extra latency/cost of fan-out) against the individual tools.

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 behavioral burden. It does disclose the key trait that everything is aggregated into 'one call' versus assembling sub-tools, and that output is risk-scored, but it says nothing about read-only safety, latency/cost of the multi-source aggregation, failure modes when a source is unavailable, or rate limits.

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 content is a single front-loaded sentence leading with the strongest hook ('One call returns...'), with no filler. However, the trailing ellipsis indicates the text is truncated, so the description is cut off rather than deliberately tight.

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 is the only source of return-value and behavior information. It lists the report's sections, which is genuinely useful, but the truncation ('…') and the absence of any guidance on the domain input format or comparison to sibling report tools leave it only marginally complete for a complex aggregation 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 0% and the single 'domain' parameter has no description in the schema. The description only restates 'for a domain' and adds no format detail (protocol prefix, subdomain handling, IDN), so it does not compensate for the coverage gap. Only the trivial single-param nature keeps this from a 1.

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 ('returns a complete intelligence profile for a domain') and enumerates the aggregated contents (WHOIS, DNS, SSL, tech stack, blacklist) plus the output form (risk-scored report). It fails to distinguish itself from heavily overlapping siblings like netintel_domain_report_full, netintel_domain_vet, and netintel_domain_due_diligence, so it lands at 4 rather than 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?

The clause 'so agents can fully vet a domain' implies the intended use case (comprehensive one-shot vetting), but there is no explicit when-to-use, when-not-to-use, or named alternative despite many sibling tools covering the same sub-tasks. Usage is implied rather than directed.

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 full behavioral burden. It does usefully disclose that sections run concurrently and degrade gracefully on partial failure, which tells the agent to expect partial results rather than a hard error. It says nothing about auth requirements, latency, rate limits, or what the 'premium' label actually costs in quota, which matters for a call that fans out to six sub-services.

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?

A single front-loaded sentence that leads with the core value proposition and then enumerates the sections; no filler. It is cut off with a trailing ellipsis, and 'premium' is unquantified marketing language, but the structure is 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?

For a one-param aggregation tool with no annotations and no output schema, the description covers scope and partial-failure behavior but omits cost/quota implications of the 'premium' framing, parameter format expectations, and any hint of the response shape or timing.

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?

There is a single required 'domain' parameter with 0% schema description coverage, so the schema adds nothing. The description names the input implicitly ('domain profile') but never states accepted formats — root domain only, subdomains, or full URLs — so format ambiguity remains.

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 states a specific verb+resource ('returns a complete six-part domain profile') and enumerates the six sections, so the agent knows exactly what it aggregates. However, it never distinguishes itself from the very similar siblings netintel_domain_report and netintel_domain_due_diligence, leaving the 'full' qualifier unexplained.

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?

'One premium call' implies the tool consolidates the six individual lookups (dns_lookup, ssl_analyze, whois_lookup, cloud_fingerprint, tech_fingerprint, security_headers), which is implied guidance for when to use it. But there is no explicit when-to-use, when-not-to-use, or any named alternative such as the lighter netintel_domain_report.

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 does disclose the shape of the result ('ranked verdict on which to use and whether it's safe to build on') and that the brand check is 'factual', but it says nothing about cost, latency, rate limits, or whether the check is purely read-only. Adequate for a read-style vetting call, but incomplete.

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 a clear verb and efficient single sentence, but the text is visibly truncated ('...check against…'), so the definition is cut off rather than tight. Conciseness is undermined by incompleteness.

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, no annotations, and 0% parameter coverage, yet the description largely conveys what comes back (ranked verdict, availability, quality, typosquat, brand collision). It leaves parameter semantics and explicit tool selection unaddressed, which is a real gap for a 4-param tool in a crowded domain-tool family.

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 0% across four parameters. The description only implies 'candidates' and 'tlds'; it gives no meaning for 'use_case' or 'deep_check_top_n', which are the parameters most likely to change behavior (depth of analysis). The description does not compensate for the schema 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 specific verbs (vet, pick) and resource (domain), and enumerates the outputs: availability across TLDs, name quality, typosquat exposure, brand-collision check. This distinguishes it from narrower siblings like netintel_domain_availability or netintel_typosquat, though it doesn't explicitly name those alternatives.

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 phrase 'in one call' implies the tool consolidates several checks that could otherwise be run separately, and 'give candidate names' implies the pre-registration naming stage. However, there is no explicit when-to-use vs when-to-use-something-else guidance against the many competing domain 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?

No annotations are provided, so the description carries the full burden. It does add real behavioral detail beyond the schema: it probes multiple DKIM selectors internally and returns a normalized A-F grade, which tells the agent the output shape. It does not state read-only/non-destructive nature, cost, or rate limits, leaving gaps for an unannotated tool.

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 tight sentences, zero waste, and the core action is front-loaded ahead of the secondary detail about selector probing and the grade output.

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 single-parameter validation tool with no output schema, the description covers what it inspects and roughly what comes back (A-F grade). Missing sibling disambiguation and parameter format details keep it from being fully complete.

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 0% and the single "domain" parameter has no schema description. The description's phrase "for a domain" implies the parameter's meaning adequately, but adds no syntax, format, or example (e.g., whether a URL or bare hostname is accepted), so it only partly compensates.

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 uses a specific verb ("Validate") with concrete resources (SPF, DKIM, DMARC records) and names the input unit (a domain). It's immediately clear what the tool does, though it offers no differentiation from siblings like netintel_email_intel, netintel_email_report, or netintel_email_verify.

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 when-to-use guidance, no prerequisites, and no mention of alternatives. In a toolset with three other email-related tools plus netintel_dns_lookup and netintel_dnssec_validate, the agent is left to guess which one to pick.

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?

No annotations are provided, so the description carries the full burden. It does disclose what the tool actually does under the hood (deliverability probing, disposable-domain detection, role-account detection, MX verification), which is useful behavior context, but says nothing about whether it performs an SMTP handshake, how authoritative deliverability results are, or any rate/permission constraints.

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?

A single front-loaded sentence with the verb first and the capability list after; every clause adds information and nothing is repeated.

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 one parameter, no annotations, and no output schema, the description covers the surface scope of the result set but omits tool differentiation and any hint of what the response contains. Minimum viable, not complete.

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% for the single required 'email' parameter. The description implicitly conveys the expected input type, but adds no format, normalization, or multi-address semantics beyond what the parameter name already suggests.

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 ('Validate an email address') and enumerates the concrete checks performed (deliverability, disposable domains, role-based addresses, MX records). However, it never distinguishes itself from the very similar siblings netintel_email_verify, netintel_email_auth, and netintel_email_report, leaving an agent to guess which email tool to pick.

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 when-to-use guidance, no prerequisites, and no named alternative. With three near-identical email siblings in the list, the absence of any routing guidance is a real gap.

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 disclosure burden. It adds one genuine behavioral detail — the sections 'run concurrently' — and flags the password check as optional, but says nothing about auth/permission needs, rate limits, cost, or the privacy implications of submitting a password to a breach service, which is a material concern for this kind of tool.

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?

A single front-loaded sentence that packs the three capabilities and the concurrency detail with no filler. It is efficient, though the trailing ellipsis suggests the provided text is truncated.

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 composite tool with no annotations, no output schema, and 0% parameter description coverage, the description covers the 'what' well but leaves the agent without output structure, section keys, failure modes, or password-handling caveats. Adequate but with clear gaps.

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 0%, so the description must compensate. It does clarify that the password input drives the 'optional password breach check', implying it is not required, but it says nothing about the email parameter's format (single address vs. list) or validation rules.

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 concrete verb and resource — combining SPF/DKIM/DMARC authentication, email-address intelligence, and a breach check into a single 'email-trust report'. It implicitly distinguishes itself from the constituent siblings (netintel_email_auth, netintel_email_intel, netintel_breach_check) by presenting itself as the aggregate, though it never names those siblings explicitly.

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?

'One call combines...' implies the tool is for when you want all three checks at once rather than calling them individually, which is useful routing context. However, it never states when to prefer this aggregate over the three separate tools, nor any exclusions or prerequisites for use.

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 most of it: it discloses the return shape (boolean-first deliverable/safe_to_send plus a machine-readable reason) and, critically, the scope limit 'DNS-level check only, no SMTP mailbox probe', which prevents the agent from over-trusting a positive result. It stops short of stating auth requirements or rate limits, so it is strong but not exhaustive.

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 clauses with zero filler, the capability summary front-loaded and the sibling routing at the end. Every element (checks performed, output shape, scope limit, alternative) 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?

No output schema and no annotations exist, so the description is the only source, and it covers the important ground: what is checked, the boolean-first output keys, and the DNS-only limitation. It could go further by naming the possible 'reason' values, which would let the agent interpret a negative result, so it is complete but not fully so.

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 0% for the single 'email' parameter, but the parameter is self-evident and the description supplies the relevant meaning: the input is an email address to be validated, and what is validated about it is spelled out (syntax, MX, provider classification). This compensates adequately for the undocumented schema, though it adds no format constraints or examples.

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?

Starts with a specific verb+resource ('Validate an email address') and immediately enumerates what is checked: syntax, MX, disposable/role/free-provider detection. It also names the sibling netintel_email_intel and the axis that separates them (yes/no gate vs. scored trust report), so the agent can disambiguate without opening either 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 phrase 'email verification before you send' gives the operative scenario, and the final sentence explicitly routes the agent elsewhere ('For a scored trust report instead of a yes/no gate, see netintel_email_intel') with the deciding condition. Both when-to-use and the alternative 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 dimensionality (384), in-house hosting, no API key requirement, cost ($0.001/call), and a batch limit of 256 texts. It omits return format and error behavior, but the disclosed operational traits are substantial.

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 most decision-relevant facts (what it is, dimension, cost, batching) in compact sentences. The trailing truncated fragment 'Pairs with /text/chunk…' is sloppy but minor.

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 3-parameter tool with no annotations, no output schema, and 0% schema coverage, the description covers behavior and cost well but leaves encoding_format undocumented and does not reconcile the 256-text batch claim with the string-typed input. Enough to invoke, not enough to invoke confidently.

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% across 3 parameters, so the description must compensate. It partially does by explaining input_type values (query/passage for e5 retrieval), but encoding_format is never mentioned and the required 'input' is left undefined. It also claims batching up to 256 texts while the schema types input as a single string, leaving the batch mechanism unexplained.

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 key attributes: multilingual 384-dim text embeddings served in-house. The 'no OpenAI dependency, no API key' framing differentiates it from netintel_openai, though it never explicitly contrasts with the similarly named netintel_v1_embeddings sibling.

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: query/passage input types for retrieval (e5) and 'pairs with /text/chunk' suggest a RAG/chunking workflow. There is no explicit when-to-use statement or stated alternative for choosing between this and netintel_v1_embeddings.

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?

No annotations are provided, so the description carries the full burden. It does disclose the underlying model (Claude Haiku) and the return shape ('structured typed arrays'), which is useful, but says nothing about input size limits, latency/cost, failure modes, or whether extraction is deterministic.

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?

One front-loaded sentence that leads with the verb and resource, then details the entity types. The closing clause 'so agents can pull structured signals out of unstructured text' restates the obvious, and the trailing ellipsis suggests truncation rather than deliberate concision.

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, no output schema, and 0% schema coverage, the description is the only documentation. It covers purpose, model, and rough return shape, but leaves input limits, the semantics of the 'types' filter when omitted, and output record fields 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 0%, so the description must compensate. It effectively documents the valid values for the 'types' filter by listing the entity categories, which the schema leaves as an unconstrained string array with no enum. It adds nothing about the required 'text' parameter's constraints (length, encoding).

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 (Extract) and resource (named entities from text) and enumerates the supported entity classes (people, organizations, locations, dates, emails, URLs, money, products). That enumeration distinguishes it from sibling extractors such as netintel_extract_contact, netintel_extract_invoice, and netintel_event_extract, which are domain-specific.

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 phrase 'pull structured signals out of unstructured text' implies the general use case, but there is no explicit when-to-use, when-not-to-use, or routing to the many sibling extractors that overlap (contact, invoice, event, table). With ~100 siblings, the absence of any alternative-routing guidance is a real gap.

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 present, the description carries the full burden and does add real value beyond structured fields: it discloses the cost profile ('cheap', 'free-ish' screening), the underlying model ('one tiny Haiku call'), latency ('fast'), and the exact return contract (is_event, confidence, one-line reason). It stops short of describing failure/ambiguity handling or any rate limit, but this is well above what the schema offers.

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 value proposition and cost rationale are front-loaded, which is good structure, but the single run-on sentence ends in an ellipsis with the thought unfinished — a defect rather than an economy. Content that remains is dense and 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, so the description correctly enumerates the returned fields (is_event, confidence, reason), which is a genuine asset. However, it leaves two of three inputs unexplained and is truncated, so an agent cannot fully reconstruct the calling contract from the description plus schema.

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% across three parameters, so the description must compensate and does not. It never mentions 'timezone' or 'posted_at', both of which are load-bearing for deciding whether text describes a dateable future event, and the truncated sentence leaves the input contract undefined.

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+resource — a binary 'is this a dateable event?' classifier over social and web text — and implicitly positions itself against full extraction ('only pay for full extraction on the ones…'), which maps onto the sibling netintel_event_extract. It is clear, though the distinguishing sentence is cut off mid-thought.

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 workflow is implied rather than stated: screen every post here, then escalate to full event extraction only for positives. No explicit when-not-to-use or named alternative is given, and the truncated clause that would have named the extraction step removes the strongest routing signal.

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 disclosure burden, and it does add real behavioral content: it names the underlying model (Claude Haiku), explains that relative dates are resolved against post time and timezone, and notes all-day/multi-day handling. However, it says nothing about auth, cost/latency of an LLM call, failure modes for unparseable text, or the return shape, and the sentence terminates mid-clause ('and returns…').

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?

It is a single dense sentence with the core purpose front-loaded, which is good, but it trails off with 'and returns…' rather than completing the thought, so the structure is compromised by an unfinished clause.

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, no output schema, and 0% schema coverage across four parameters, the description should do more. It adequately covers the extraction behavior and relative-date resolution, but the return value is cut off and the city parameter is unexplained, leaving gaps an agent would have to guess at.

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, and it partially does: 'resolves relative dates … against the post time and timezone' maps to posted_at and timezone, and the input domain maps to text. The 'city' parameter is never mentioned or explained, leaving one of four parameters undocumented in both the schema and the description.

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 ('Extract a normalized calendar event') and scopes the input domain ('any caption, announcement, or page text'), which distinguishes it from generic extractors like netintel_extract. It never names netintel_calendar or netintel_event_classify, so the agent must infer the boundary with those siblings rather than being told.

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 phrase 'from any caption, announcement, or page text' implies the applicable input context, but there is no explicit when-to-use/when-not guidance and no routing to netintel_event_classify or netintel_calendar. Usage is inferable but not 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?

No annotations are provided, so the description carries the burden. It discloses the return shape (numbered citations with title, url, published_date) and that the answer is grounded in a live web search, which is meaningful behavioral context. It stops short of covering latency, source recency limits, or failure modes, but the core output behavior is clear.

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 clauses, front-loaded with the action and output, then the routing hint. No wasted words.

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 search tool with no output schema, the description covers purpose, output format, and the primary alternative. The only omission is naming the include_citation_text parameter, which is minor given the schema does at least list it.

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 0%, so the description must compensate. The query parameter is self-evident, and include_citation_text is implicitly supported by the mention of citations, but the description never names or explains that boolean toggle. Partial compensation 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 ('Ask a question, get a direct answer grounded in a live web search') and explicitly distinguishes itself from the ranked-results sibling netintel_exa_search. The 'One call replaces search + read + summarize' framing makes the purpose unambiguous.

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?

Explicitly routes the agent: use this for a synthesized answer with citations, use /exa/search for ranked results. The when-to-use and when-to-use-something-else conditions are both 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. It usefully discloses the batch cap (3 URLs), the fallback behavior (index + live crawl), and that results are per-URL with status, which is real behavioral context. It omits auth requirements, rate limits, cost, and failure semantics for blocked URLs.

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?

Dense and front-loaded: capability, mechanism, and return shape arrive in the first two clauses with no filler. The only defect is that the text is cut off mid-sentence, which harms structure.

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 output schema and no annotations, the description does cover the return shape (title, author, published_date, text, per-URL status) and the crawl strategy well. But with 0% parameter coverage and a truncated tail, an agent still lacks guidance on livecrawl and max_characters.

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% across three parameters, so the description must compensate. It adds a batch constraint (up to 3 URLs) not present in the schema, but never explains the 'livecrawl' string parameter or 'max_characters' numeric parameter, leaving two of three parameters undocumented anywhere.

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 ('clean page text for up to 3 URLs in one call') plus the mechanism ('Exa's index + live crawl'). It implicitly distinguishes itself from a direct-fetch sibling by claiming JS-rendered and bot-walled support, but the truncation ('Pairs with…') cuts off the explicit sibling differentiation, so it lands just 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?

The claim that it 'works on JS-rendered and bot-walled pages that direct fetch can't read' implies when to prefer it over a plain fetch tool. However, there is no explicit alternative named, no when-not guidance, and no cost or rate-limit caveats — usage is inferred 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 add real value: it discloses the ranked result shape (title, url, published_date, author, score), optional highlight snippets, and that results are 'live'. It omits auth requirements, rate limits, pagination, and cost, so it is only partly transparent for a search call.

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 is front-loaded in a single efficient sentence, but the trailing 'domain…' ellipsis signals a truncated or unfinished description, which undercuts clarity and looks like copy that was cut off mid-list.

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 an 8-parameter tool with 0% schema coverage, no annotations, and no output schema, the description should document the tunable parameters and their formats. It covers return fields well but leaves num_results, type, and the date-range filters unexplained, so an agent cannot select good parameter values from the definition alone.

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% across 8 parameters, so the description must compensate. It explains only 'category' (with examples), domain filtering, and snippets; it says nothing about num_results, type, or start/end_published_date, leaving half the parameters undocumented in both places.

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 ('Exa neural web search') and enumerates the return fields, so the agent knows exactly what kind of search this is. It does not, however, distinguish itself from closely-named siblings like netintel_exa_contents, netintel_exa_answer, or netintel_web_search, leaving the agent to guess which Exa endpoint fits.

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 says it is 'for AI agents' and lists filters, but never states when to choose this over netintel_exa_answer, netintel_exa_contents, or netintel_web_search, nor any prerequisite or exclusion. Usage must be inferred entirely from the tool name.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the underlying model (Claude Haiku) and the exact output shape, but says nothing about how unparseable/ambiguous input is handled, latency, cost, or failure modes.

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?

A single front-loaded sentence that leads with the action and then the output fields; no redundant filler. It ends truncated ('for…'), which slightly undercuts the structure but the informative content is delivered up front.

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, the description usefully enumerates the return fields, so an agent knows what it will get back. The remaining gap is edge-case behavior on invalid input, which matters for a parser but is 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?

One required parameter with 0% schema description coverage, so the description must compensate. 'freeform address string' does add the key semantic (unstructured, any format accepted), but gives no format hints, limits, or examples to compensate for the empty 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 pair (parse and normalize) and the resource is precisely bounded: a freeform address string. It enumerates the split outputs (street, city, state/region, postal code, country, normalized single-line), which clearly separates it from generic siblings like netintel_extract_contact, netintel_extract_invoice, and netintel_normalize.

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 trailing clause 'so agents can clean and standardize messy address data' implies the use case but gives no explicit when-to-use/when-not and names no alternative (e.g., when to prefer extract_contact for addresses embedded in documents). Usage is inferable but not 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. It does disclose the underlying model (Claude Haiku) and the exact output shape, which is useful context. It says nothing about behavior on sparse or ambiguous input, multi-contact handling, latency/cost implications, or what happens when a field is absent, leaving real gaps for a no-annotation tool.

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 verb and resource, then the output contract, in a single dense sentence with no filler. The trailing ellipsis indicates the text is truncated, so the full definition may not be as tight as the visible portion.

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. For a one-parameter, read-only extraction tool with no annotations, the visible text covers purpose, input sources, and return shape adequately, though error/edge-case behavior is 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 0% and the single 'text' parameter has no description. The description partially compensates by indicating the accepted input forms (raw text, email signature, webpage text), but says nothing about size limits, whether HTML is acceptable, or how multiple contacts in one input are handled.

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 (extract) and resource (structured contact details), names the accepted input forms (text, email signature, webpage text), and enumerates the returned fields (name, title, company, email, phone, address). This clearly separates it from siblings like netintel_entity_extract, netintel_extract_resume, and netintel_extract_invoice.

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 clause 'so agents can turn unstructured contact blocks into CRM-ready…' implies the intended scenario, and the listed input sources hint at when the tool fits. However, it never states when NOT to use it or names an alternative for adjacent cases such as general entity extraction or resume/invoice parsing, so usage is only implied.

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 behavioral burden, and it does disclose two useful traits: the backing model ('using Claude Haiku' — relevant for cost/latency/accuracy expectations) and the return shape (a flat JSON list of fields, valuable since no output schema exists). It does not disclose input constraints (e.g. that only plain text is accepted, not PDFs or images), size limits, or behavior on non-invoice input.

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?

It is a single front-loaded sentence with the purpose first and the return payload after, which is sound ordering. But the description visibly terminates mid-clause with an ellipsis ('expense processing, and…'), leaving an obviously unfinished thought rather than an intentionally concise statement.

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 one-parameter, no-annotation, no-output-schema tool, the description supplies the essentials: what it extracts, what it returns, and which model does the work. An agent can call it correctly from this text. The remaining gap is input eligibility — nothing clarifies whether PDFs, images, or only pre-extracted text are acceptable.

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?

There is one parameter ('text') at 0% schema description coverage, so the schema adds nothing. The phrase 'from invoice or receipt text' implies the input should be raw extracted text rather than a file, URL, or image, which is genuinely useful. Beyond that, format, length limits, and quality expectations for the input are unstated.

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 — 'Extract structured data from invoice or receipt text' — and enumerates the target fields (vendor, invoice number, dates, line items, subtotal, tax, total, currency). The invoice/receipt domain implicitly separates it from generic siblings like netintel_extract, netintel_extract_table and netintel_extract_resume, but no sibling is ever named. The sentence is also truncated with an ellipsis, so the stated purpose is materially cut off.

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 implies usage through example scenarios ('automate accounts-payable, expense processing...'), giving an agent a sense of the intended context. However, it names no alternatives and no exclusions: nothing tells the agent to prefer netintel_pdf_parse or netintel_extract_table for PDFs/tables, or netintel_extract_contact for non-financial documents. Usage is only implied, not guided.

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 supplied, the description carries the full behavioral burden; it does disclose the backing model (Claude Haiku) and the shape of the return value (clean JSON arrays with named fields), which is real added context. It omits input size limits, behavior on non-resume input, latency/cost implications, and error handling, so a mutation-free but model-backed call still has notable blind spots.

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?

One front-loaded sentence: verb, resource, output fields, then use cases. No filler. The trailing ellipsis suggests the text is truncated, which slightly weakens an otherwise tight structure.

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 does useful work by enumerating the returned fields, but it leaves gaps an agent needs: input limits, how non-resume text is handled, and any failure modes. Adequate, not complete, for a model-backed extraction 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?

There is a single required parameter, 'text', with 0% schema description coverage, so the schema says nothing about its format or constraints. The description only hints that it should be resume/CV text; it doesn't state whether raw pasted text, file content, or a URL is expected, nor any length bounds.

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?

It names a specific verb (extract), a specific resource (resume/CV text), and the exact fields returned (name, contact info, skills, work experience, education). This cleanly separates it from the nearby generic siblings netintel_extract, netintel_extract_contact, netintel_extract_invoice and netintel_extract_table without the agent needing to open any 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 gives downstream scenarios (applicant screening, candidate databases, recruiting), which implies when the tool is useful, but it never states when NOT to use it or which sibling to pick for non-resume text extraction. Usage is inferable rather than specified.

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?

No annotations are provided, so the description carries the full burden, but it does disclose useful behavioral traits: the backing model (Claude Haiku, implying cost/latency profile) and the exact return shape (columns + rows). It says nothing about size limits, behavior on non-tabular input, failure modes, or cost, and it is cut off mid-sentence, leaving the behavioral picture incomplete.

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 is front-loaded well, but the description terminates mid-clause with "into…", leaving a visibly unfinished sentence and unresolved content. It is also a single run-on sentence that tries to carry purpose, mechanism, and output in one breath.

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 one-parameter tool with no annotations and no output schema, the description covers the essentials — accepted input forms and the returned structure (columns + rows). The truncation and the absence of any input constraint (size, HTML vs. plain text handling) leave gaps for an agent deciding whether to call it.

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?

There is a single parameter with 0% schema description coverage, so the description must supply the semantics. It partially does: the input is messy text or HTML content ("pasted tables, HTML tables, and delimited text"), implying content rather than a URL. It never states format, size, or whether a URL is accepted, so the one undocumented param is only partly compensated for.

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 ("Extract tabular data") and adds the mechanism ("detects columns and rows") plus the output shape ("clean structured JSON (columns + rows)"), so the purpose is unambiguous. It does not, however, distinguish itself from near-neighbors in the large extract family (netintel_extract, netintel_text_to_json, netintel_schema_parse), so the agent must infer the boundary.

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?

Input types named — "pasted tables, HTML tables, and delimited text" — imply when the tool applies, which is real but indirect guidance. There is no explicit when-not condition and no sibling alternative is named, so the agent gets no routing help among the many other extraction tools.

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 it does add real behavioral context: keyless (no credentials needed), single-call multi-chain coverage, and 'live' freshness. It also previews the return shape (gas price plus EIP-1559 base/priority fee in gwei) before being truncated. It stops short of disclosing rate limits, caching, or failure modes per chain, so it is useful but incomplete.

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 text is dense and front-loads the resource and chain list before the value proposition, which is well ordered and waste-free. However it ends mid-sentence with a trailing ellipsis, indicating the definition is truncated rather than deliberately concise. Compact but structurally unfinished.

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 must explain both behavior and returns; it partially does, naming per-chain fields and units (gwei). What is missing is how the 'chains' argument is supplied and whether the default is all chains. For a single-param read tool this is workable, but not fully self-contained.

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 has one parameter, 'chains', with 0% description coverage, so the description must compensate. It lists supported chains, which implies valid values, but never states the parameter's format (comma-separated list vs. repeated arg), whether it is optional, or what happens if omitted. The ellipsis truncates before any such detail.

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 resource (live gas prices), enumerates the exact chains covered (Base, Ethereum, Arbitrum, Optimism, Polygon), and states the delivered value (USD cost estimates for transfer, ERC-20 send, and swap). No sibling tool covers gas pricing, so there is nothing to confuse it with. An agent knows immediately what this tool produces.

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 rather than stated: 'keyless, one call, all chains' signals it is a batched, no-auth lookup worth preferring over per-chain calls. However, the description never says when to reach for this versus related tools like netintel_crypto_price or netintel_market_snapshot, nor any prerequisite or exclusion. Adequate but leaves routing 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 behavioral burden. It usefully enumerates what is computed (maintenance score, activity, license), which implies an analysis/read operation rather than a mutation, but it never states that the call is read-only, whether a GitHub token or rate limit applies, or how stale the activity data might be.

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 compact clauses with no filler; the purpose and return contents are front-loaded and the format requirement follows. Every fragment 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?

For a one-parameter read tool with no output schema, the description covers the essentials: what is analyzed, what comes back, and the input format. The only real omission is the safety/auth profile that annotations would normally supply.

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 schema alone leaves the single parameter undocumented. The description compensates by specifying the expected 'owner/repo' format, which is exactly the missing semantic detail for this 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 (Analyze) plus resource (GitHub repo) and enumerates the returned metrics (stars, forks, activity, license, open issues, maintenance score), so the agent knows exactly what it gets. It does not explicitly differentiate from near-siblings like netintel_npm_intel or netintel_tech_fingerprint, though the resource name makes the distinction fairly obvious.

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 no when-to-use context, no prerequisites, and names no alternative tool. The only guidance present is the input format instruction, which is parameter-level rather than usage-level.

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?

No annotations and no output schema, so the description carries the full behavioral burden, yet it says nothing about return format, permissions, or how a specific date is actually evaluated. The 'business day or weekend' claim is also ambiguous since no day-of-month parameter exists to express a target date.

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, front-loaded sentences with no filler; the primary purpose leads and supporting facts follow. It is terse to the point of under-specification rather than verbose.

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 3-parameter tool with no annotations, no output schema, and 0% parameter coverage, the description is too thin. It omits how year/month shape results and how the business-day check is invoked, leaving real gaps an agent would hit at call time.

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% across three parameters. The description helpfully specifies the country format (ISO 3166-1 alpha-2), but leaves 'year' and 'month' entirely unexplained, including whether they are required to list holidays or filter results.

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 ('Get public holidays by country') and adds a second concrete capability (business day/weekend check). It is clear what the tool does, though it does not explicitly differentiate itself from nearby tools like netintel_calendar since no sibling covers holidays.

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 stated capabilities: fetching holidays and checking whether a date is a business day or weekend. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g., netintel_calendar), so the agent must infer the context.

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 behavioral burden and does reasonably well: it declares offline operation, determinism, immediacy, no upstream calls (implying no auth, network, or rate limits), the ~80-country coverage envelope, and notably the error semantics — an invalid IBAN returns 'valid:false' rather than throwing. The trailing truncation leaves the return payload only partially 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?

A single front-loaded sentence with an em-dash enumeration; the verb and resource come first and the differentiating traits (offline, deterministic, fast) follow. The list of checks is dense but each item earns its place. Only the truncation prevents a 5.

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 one-parameter, no-annotation tool, the description covers purpose, scope, safety profile, and even the negative-result contract. With no output schema, it should ideally spell out the full return shape (extracted bank/branch, formatted IBAN), which it only gestures at before cutting off.

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?

One required parameter at 0% schema coverage, so the schema contributes nothing beyond the name 'iban'. The description makes clear the input is an IBAN to be validated but adds no format guidance (spaces, lowercase, country prefix, length limits), which is the main remaining ambiguity. Adequate but not compensating 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 ('Validate any IBAN') and immediately enumerates the substance of the validation: mod-97 check digits, per-country structure, bank/branch extraction, pretty formatting. It also scopes coverage ('~80 countries'), so an agent knows exactly what it gets. No sibling tool validates IBANs, so no in-family confusion is possible.

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 context is implied rather than stated: 'offline ... deterministic, instant, no upstream' tells the agent this is a zero-dependency local check and therefore safe to call freely, which is useful selection signal. However, there is no explicit when-to-use/when-not framing or named alternative, so guidance is only implied.

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. It discloses the scope (15 blacklists) and the return content (threat level and matching lists), which gives some operational transparency, but it omits whether the operation is read-only, whether authentication or rate limits apply, and any side effects. For a lookup tool this leaves notable gaps.

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 sentences, front-loaded with the core purpose and followed by the return summary. Every word earns its place with no redundancy or 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 simple one-parameter lookup with no output schema or annotations, the description adequately covers the tool's scope and return values. The main missing piece is usage context relative to siblings, but that is largely captured in the usage guidelines dimension.

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 input schema has 0% description coverage for the single 'ip' parameter. The description says 'an IP address' but provides no format details (e.g., IPv4 vs IPv6, whether CIDR is accepted) to compensate for the schema's silence, adding little beyond what the parameter name already implies.

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 states a specific verb (Check) and resource (IP address against DNS blacklists), and even names example lists and the return type. It does not, however, differentiate this tool from siblings like netintel_ip_reputation or netintel_ip_risk, so an agent must infer the distinction from the description alone.

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 guidance on when to use this tool versus alternatives, no prerequisites, and no indication of when it is inappropriate. The description only states what the tool does, not when to choose it.

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?

No annotations are provided, so the description carries the full burden. It names the output fields, which is useful, but says nothing about whether IPv4/IPv6 are accepted, how private/reserved ranges behave, rate limits, caching, or any notion of reliability for geolocation 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?

A single front-loaded sentence: verb first, then the field list. No filler, no redundancy. Appropriately sized for a one-parameter lookup tool.

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 single-param, no-output-schema lookup the description covers what comes back, which is the main gap. It is still thin on input format and on how this differs from the numerous overlapping IP/ASN siblings, so an agent could plausibly pick the wrong 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?

One required parameter with 0% schema description coverage. The description implies the input is 'an IP address' but gives no format guidance (IPv4 vs IPv6, CIDR rejection, required-ness), so it only partially compensates for the schema 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 ('Geolocate') and resource ('an IP address') and enumerates the returned fields (country, city, coordinates, ISP, ASN, timezone), so the agent knows exactly what it gets. However, it offers no differentiation from close siblings like netintel_asn_lookup, netintel_ip_reputation, or netintel_ip_report, which overlap on ASN/IP 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?

No indication of when to choose this over netintel_asn_lookup, netintel_ip_reputation, netintel_ip_risk, or netintel_ip_report. The agent is left to infer that 'geolocation' is the distinguishing feature, with no exclusions or prerequisites 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?

No annotations are provided, so the description carries the full burden. It does add genuine behavioral context beyond the schema — concurrent execution and 'graceful partial-failure handling' tells the agent this call is resilient and may return partial results. But it omits cost specifics beyond the word 'premium', any latency expectations, whether the IP is passed to third-party blacklist services, and how partial failures surface in the response.

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?

It is a single dense sentence that front-loads the value proposition well, packing the five components into one scannable clause. But the text terminates mid-sentence ('...so…'), which reads as truncated rather than deliberately concise, leaving an incomplete thought in the description an agent actually consumes.

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 is the only source of behavioral and structural information, and it partially compensates by listing the five profile components — effectively describing the return shape. Still, the truncated ending, the undocumented 'ip' parameter, and the absence of any cost or partial-result semantics leave it short of complete for a 'premium' aggregator 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?

There is one required parameter, 'ip', with 0% schema description coverage, so neither the schema nor the description defines it. The name makes the intent obvious, but the description never specifies accepted formats (IPv4/IPv6/range/hostname) or validation behavior — a real gap since bad input is the most likely failure mode for a one-param tool.

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 ('One premium call returns a complete five-part IP profile') and enumerates exactly what the profile contains — geolocation, ASN/network ownership, DNSBL blacklist status, threat reputation, and a risk verdict. This implicitly distinguishes it from point-solution siblings like netintel_ip_geo, netintel_ip_blacklist, netintel_ip_reputation, and netintel_ip_risk as the aggregate/roll-up tool. The sentence is cut off mid-clause, so the pitch is clear but not fully closed.

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 phrase 'One premium call returns a complete five-part profile' implies this is the consolidated alternative to calling the individual IP tools separately, which is useful routing context. However, there is no explicit statement of when to prefer this aggregation over netintel_ip_geo / netintel_ip_blacklist / netintel_ip_reputation, nor any exclusion guidance. Usage is implied 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 behavioral burden. It usefully discloses the external data sources and some return contents, and the verb 'screens' implies a read-only lookup, but it omits auth/rate-limit behavior, error handling, and any explicit confirmation that the operation is non-destructive.

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?

A single, front-loaded sentence with no filler. It efficiently names the resource, the sources checked, and the key outputs.

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 one-parameter lookup with no output schema, the description adequately covers what the tool does, where data comes from, and what is returned. It is only slightly incomplete on input format and how the composite risk score should be interpreted.

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 should compensate for the bare 'ip' parameter. It only says 'an address' and does not clarify IPv4/IPv6 support, expected format, or whether CIDR/hostname inputs are valid.

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 states a specific verb and resource ('IP reputation and malicious-IP check') and names the external threat feeds (AbuseIPDB, AlienVault OTX) plus the return contents. It does not explicitly differentiate this tool from siblings like netintel_ip_risk, netintel_ip_blacklist, or netintel_ip_report, so it falls 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?

There is no when-to-use guidance, no exclusions, and no mention of alternative IP intelligence tools in the sibling list. Usage is only implied by the tool name and description, leaving selection against similar tools 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. It does disclose meaningful behavior: this is a multi-source aggregator whose output is a synthesized verdict rather than raw lookups. However, it says nothing about input format constraints (IPv4 vs IPv6), latency from multiple external lookups, rate limits, or failure modes when a source is unavailable.

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?

A single front-loaded sentence whose lead ('One call returns a complete risk profile') carries the core value proposition, followed by an enumeration that justifies what 'complete' means. The em-dash-heavy listing is dense but each element is informative; the only weakness is the trailing truncation.

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 exist, so the description must convey the result shape — and it does by naming the four data classes that compose the profile and the aggregated verdict. For a simple single-parameter read tool this is largely sufficient, though it omits input format and any caveats about source coverage.

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?

One required parameter ('ip') with 0% schema description coverage. The description's phrase 'for an IP address' restates the parameter name but adds no format, scope, or validation detail. The parameter is near self-describing, so this is only a minor gap rather than a severe one.

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 ('returns a complete risk profile for an IP address') and enumerates the bundled data (geolocation, ASN/network owner, DNSBL blacklist status, proxy/VPN/hosting classification) plus the aggregation into a single verdict. This implicitly separates it from single-purpose siblings like netintel_ip_blacklist and netintel_ip_geo, but no sibling is named explicitly.

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 trailing clause 'so agents can make a block/allow…' implies the decision context in which the tool is useful, which is real but generic guidance. There is no explicit when-to-use vs when-not, no statement that you should pick this instead of calling ip_geo + ip_blacklist separately, and the sentence is truncated mid-thought.

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 behavioral burden, and it does disclose one meaningful trait: a deterministic tokenizer runs first at no LLM cost, implying an optional paid LLM path. It says nothing about failure behavior on unrepairable input, idempotency, or what is returned when repairs are partial.

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 and dense: purpose first, then the defect list, then the execution/cost note. The single long enumerated sentence is efficient, though it reads as a list dump and the trailing "with an…" shows the content is cut off mid-clause.

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 4-parameter tool with zero annotation coverage, 0% schema coverage, a nested-object parameter, and no output schema, the description should at minimum explain `coerce`/`schema` and the shape of success vs. failure. It covers the repair domain well but leaves roughly half the calling contract undocumented.

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% across 4 parameters, so the description must compensate, and it only gestures at two: `input` (malformed JSON) and `allow_llm` (via the no-LLM-cost tokenizer note). `coerce` and `schema` — including the nested object structure — are never explained, leaving their semantics entirely opaque.

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 precise verb+resource ("Repair malformed JSON into valid JSON") and enumerates the exact defect classes handled — code fences, trailing commas, single quotes, unquoted keys, bad escapes, duplicate keys, truncation, JSON buried in prose. That enumeration functionally separates it from conversion/extraction siblings such as netintel_text_to_json or netintel_extract, even though none are named.

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: the input is evidently malformed JSON text. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g. text_to_json for clean prose-to-JSON conversion). The mention that a deterministic tokenizer runs first hints at the cost tradeoff but is not framed as guidance.

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 of behavioral disclosure. It implies a read-only inspection by using 'Decode', 'inspect', 'check', and 'flag', but it does not state whether signature verification is performed, what permissions or inputs are required, or how the results are returned.

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?

A single front-loaded sentence with no filler. The primary action is first, and the additional capabilities are listed compactly after the dash.

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 convey return behavior. It sketches outputs as header, payload, expiry, and security flags, but omits important details such as signature verification status and return format.

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 description coverage is 0% for the single required parameter. The description compensates minimally by identifying the input as a JWT token, but it adds no format or syntax details beyond what the property name 'token' already suggests.

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 (Decode) and resource (JWT token), then enumerates the concrete functions: inspect header and payload, check expiry, flag security issues. Sibling tools contain no other JWT-specific tool, so it is clearly distinguishable.

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 implies use for analyzing a JWT token, but it does not explicitly state when to use this tool versus alternatives or when not to use it. No prerequisites are mentioned.

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 usefully discloses that output includes a confidence score and that 50+ languages are supported, but says nothing about minimum text length, mixed-language behavior, accuracy limits, or auth/cost. Partial behavioral coverage only.

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