marketing-compliance

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds context about the feed's content (competitor, regulatory, narrative) and that it is 'Daily-rebuilt,' but it does not disclose the return format, pagination, potential rate limits, or whether the operation is read-only. This leaves significant gaps for a tool that likely returns a non-trivial dataset.

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 concise: two sentences that front-load the action and resource, with no filler words. Every sentence adds value—first defines the core function, second clarifies the feed's nature and content.

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 tool is simple (1 parameter, no nested objects, no output schema), and the description provides sufficient context about the feed's content and time window. However, without an output schema, a brief note about the return shape (e.g., 'returns a list of signals') would improve completeness. As is, it is adequate for the tool's simplicity.

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 covers 100% of the single parameter 'days,' including default, minimum, and maximum. The description's phrase 'last N days' aligns with the schema but adds no extra meaning. Since schema coverage is high, the baseline of 3 is appropriate.

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 clearly states the tool's action: 'Return the last N days of NorthPoint's competitor + regulatory + narrative signal feed.' It specifies the resource (signal feed) and the scope (time window), and the mention of 'Daily-rebuilt digest' distinguishes it from sibling tools like search_signals, which likely performs searches rather than serving a feed.

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 a clear use case: retrieving recent signal feed data. However, it does not explicitly state when to prefer this tool over alternatives like search_signals or other run_* check tools. There is no mention of exclusions or contrasting scenarios, so the guidance is moderately implied but not fully 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 provided, the description carries the burden. It discloses that the tool is free, requires no API key, and involves no round trip, and the verb 'Return' implies a read-only operation. It does not explicitly mention rate limits or failure modes, but for a simple retrieval this is acceptable.

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 well-structured and front-loaded, stating the core action in the first sentence. The subsequent sentences provide usage guidance and alternatives without redundant fluff, making every sentence valuable.

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 retrieval tool with no output schema, the description provides all necessary context: what it returns, why it exists, when to use it, and how it differs from the pro-check alternatives. It is complete and 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?

Schema description coverage is 100%: the only parameter 'regime' is fully described with an enum list. The tool description adds no extra parameter-level detail beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description clearly states the tool returns the FREE lite ruleset for one regime as markdown, specifying the resource and format. It also distinguishes itself from the run_*_pro_check tools by noting it needs no API key and no round trip, making it unique among siblings.

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

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

Explicitly says 'Use this to check crypto/fintech marketing copy...' and contrasts with the alternative: 'For the full 25-40 rule audit... use the corresponding run_*_pro_check tool (subscriber key required).' This clearly defines when to use this tool versus 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. It discloses that 'No API key required' and describes the output (regimes with free/subscriber rule counts). It does not explicitly say 'read-only' but 'List' clearly implies a non-destructive operation, and the simplicity of the tool makes this sufficient.

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 two sentences, front-loaded with the verb and resource, and every phrase adds value (list, regimes, counts, no key, call first). There is zero redundancy or fluff.

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 zero-parameter discovery tool with no output schema, the description fully covers what it returns (regimes and counts), why to use it (discover availability), and any prerequisites (none). The enumerated regime list gives practical context for an agent deciding next steps.

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 tool has zero parameters, so the baseline is 4. The description does not need to clarify parameters; it adds context by enumerating the regimes returned, which is output semantics rather than parameter semantics. No deduction is needed.

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 clearly states the tool lists every marketing-compliance regime NorthPoint can check, with specific examples (MiCA, FCA, GDPR, etc.) and includes rule counts. This distinguishes it from the sibling run_* tools that actually perform compliance checks.

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 explicitly says 'Call this first to discover what is available,' which provides clear when-to-use guidance and implies this is a discovery tool before running specific checks. It does not explicitly name alternatives but the sibling tool names make the distinction obvious.

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?

Without annotations, the description carries the full behavioral burden. It discloses key behaviors: 'extracts on-image text, evaluates prominence/contrast/dark patterns/disclosures, and returns a full audit'. This gives a solid understanding of processing steps and outputs, though it omits failure modes and side effects.

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 two sentences, front-loading the main purpose and then efficiently covering inputs and behavior. Every sentence earns its place without redundancy or 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?

Given five optional parameters and no output schema, the description provides useful usage patterns but leaves ambiguity about parameter combinations (e.g., what happens if multiple inputs are passed together). The listed evaluation criteria and 'full audit' output give a good overall sense of the tool's 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?

The schema already has 100% parameter coverage, so the baseline is 3. The description adds value by clarifying input relationships: 'Pass an image URL, base64 image, or just a landing-page URL plus caption', which implies mutual alternatives and a common usage pattern beyond individual parameter definitions.

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

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

The description opens with 'Cross-jurisdiction ad-creative compliance scan (~30 rules)', giving a specific verb phrase ('compliance scan') and a clear resource (ad creatives). It distinguishes itself from sibling compliance check tools by targeting ad creatives specifically, and further clarifies the output ('returns a full audit').

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

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

The description provides explicit input alternatives: 'Pass an image URL, base64 image, or just a landing-page URL plus caption'. This gives clear context on what arguments to provide and how they combine, though it does not explicitly name alternative tools or exclusion conditions.

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 of behavioral disclosure. It explains the audit's core behavior (analyzes whether engines will cite the project, identifies gaps stopping it) and details the return values: a 0–100 citeability score, per-engine read, per-rule analysis, and ranked fix list. It does not mention rate limits or auth, but as a read-only audit tool, the key behavior is well covered.

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 four sentences, each conveying useful information: the action, the analysis performed, the output structure, and a positioning statement. It is efficiently structured and front-loaded with the key purpose. The final 'successor to SEO' phrase is slightly extraneous but not distracting.

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?

Given there is no output schema, the description compensates by clearly listing the output components (citeability score, per-engine read, per-rule analysis, ranked fix list). It also mentions the 12 rules. However, it does not clarify that at least one of url or text is needed for the audit, which is a minor omission for completeness.

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 100%, so the input schema fully documents the three parameters (url, text, asset_type). The description adds no additional parameter-specific details beyond the schema, but it does mention the audit scope in general. This meets the baseline of 3, but doesn't exceed 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?

The description explicitly states it runs an AEO/GEO visibility audit with 12 rules, analyzing whether AI answer engines (ChatGPT, Perplexity, Claude, Gemini) will cite the project. This clearly differentiates it from sibling tools such as run_gdpr_pro_check or run_ad_creative_check, which target different domains.

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 clear context for when to use this tool: to assess AI answer engine citeability and identify gaps. It does not explicitly exclude alternatives, but the sibling tools are distinct regulatory/creative checks, making the use case unambiguous. The added note 'The 2026 successor to SEO' further implies its role in modern visibility auditing.

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 of behavioral disclosure. It reveals the output ('verdict + per-rule analysis + rewrite suggestions') and scope (~25 rules, specific regulations), but does not explicitly state that the tool is read-only, has no side effects, or that it performs server-side fetching without persisting data. It adds some useful context but leaves safety profile implicit.

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 two sentences, front-loaded with the action ('Run'), and every sentence provides substantive value: scope, legal references, and return format. No filler or repetition of schema details.

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 covers the tool's purpose, legal framework, and return payload in enough detail for an audit tool with 3 well-defined parameters. It lacks mention of rate limits, authentication, or runtime expectations, but these are less critical for a straightforward compliance-analysis tool. The absence of an output schema is mitigated by the explicit list of return components.

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 descriptions cover 100% of the three parameters, so the baseline is 3. The tool description adds context about the audit's legal scope and output, but does not provide additional meaning for the parameters themselves beyond what the schema already states. No compensation for a low-coverage situation is needed.

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 clearly states a specific verb+resource: 'Run the full FCA UK financial-promotions self-audit for cryptoasset marketing'. It lists concrete regulatory references (Section 21 FSMA, COBS 4.12A, PERG 8) and distinguishes from sibling tools like run_mas_pro_check or run_sec_pro_check by explicitly naming the FCA UK jurisdiction and cryptoasset scope.

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 clear context (UK FCA financial-promotions audit for cryptoassets) and implies when to use it, but does not explicitly mention alternative tools or exclusions like 'use this for FCA matters, not for MAS/SEC'. The regulatory specificity effectively signals the intended use case, but explicit exclusions are absent.

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 disclosure burden. It usefully discloses the audit breadth (~30 rules across six coverage areas) and the return format (verdict, per-rule analysis, rewrite suggestions). However, it does not explicitly confirm whether the operation is read-only or clarify the precedence when both 'url' and 'text' are supplied.

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 two sentences that front-load the core purpose ('Run the full GDPR + ePrivacy marketing self-audit (~30 rules)') and then list coverage areas and outputs. Every clause earns its place—rule count, scope, and returns are all material—with 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?

With no output schema, the description correctly explains returns (verdict, per-rule analysis, rewrite suggestions), and the coverage list sets accurate expectations for a 30-rule audit. Minor gaps remain around operational details like url-versus-text precedence and explicit read-only confirmation, but the rich schema and clear scope make this largely 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 100%—all three parameters (url, text, asset_type) are well-documented, including the SSRF guard note and exhaustive asset-type examples. The description adds contextual framing about what the audit examines but no per-parameter meaning beyond the schema, so the baseline of 3 applies.

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

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

The description uses a specific verb and resource ('Run the full GDPR + ePrivacy marketing self-audit (~30 rules)') and further delimits scope with a concrete coverage list (cookie banners, email/SMS opt-in, signup forms, privacy notices, marketing automation, ad-pixel placement). The GDPR/ePrivacy focus clearly distinguishes it from sibling regime-specific tools like run_fca_pro_check and run_sec_pro_check.

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 usage context is implied through the 'marketing self-audit' phrasing and the asset types in the schema (landing page, ad, email, etc.), but no explicit when-to-use or when-not-to-use guidance is given. Alternatives such as get_lite_ruleset for a lighter check are not mentioned, and no exclusions 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?

No annotations are provided, so the description bears the burden of behavioral disclosure. It states that the tool runs an audit and covers ~35-40 rules, which implies read-only analysis, but it does not describe what output is returned, whether it requires url or text input, or any side effects. This is adequate but minimal.

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 conveys scope, jurisdiction, and content without redundant words. Every element 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?

This is a complex legal audit tool with no output schema and no required parameters. The description explains scope but omits expected return format, whether the tool can run without any input, and how url/text relate. The schema mitigates some gaps, but the missing operational detail leaves room for uncertainty.

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 already provides thorough descriptions for all three parameters (url, text, asset_type) with 100% coverage. The description adds regulatory context but does not enrich the parameter semantics beyond what the schema already defines, so baseline 3 is appropriate.

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 ('Run') and clearly identifies the resource ('full MAS Singapore DPT marketing self-audit') with a rule count. It distinguishes itself from siblings like run_fca_pro_check and run_mica_pro_check by naming the jurisdiction and topic.

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 clearly indicates the tool is for MAS Singapore DPT marketing audits and lists the legal regimes involved. It does not explicitly name alternatives or exclusions, but the jurisdiction and regulatory citations make the intended use obvious in the context of sibling 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 burden of behavioral disclosure. It describes the output (verdict, per-rule analysis, rewrite suggestions) but does not explicitly state that the tool is read-only or free of side effects. The term 'self-audit' implies analysis only, but explicit disclosure is lacking.

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 two sentences, front-loaded with the main action. It efficiently covers scope (rules count, regulatory references) and output without extraneous wording.

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?

Despite no output schema, the description clearly states what the tool returns (verdict, per-rule analysis, rewrite suggestions) and defines the scope (Title II–IV, ESMA guidance). This is complete enough for an agent to understand when and how to invoke 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 description coverage is 100%, providing detailed descriptions for url, text, and asset_type. The description adds no parameter-specific meaning, but the schema already covers the semantics, so the baseline of 3 applies.

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

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

The description states a specific action: 'Run the full MiCA (EU cryptoasset marketing) self-audit on a marketing asset.' It clearly identifies the regulatory scope (MiCA, EU cryptoasset marketing) and distinguishes from sibling tools by referencing the specific regime and asset type.

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 for MiCA self-audits on marketing assets, which provides clear context. However, it does not explicitly mention when not to use it or compare to alternatives like run_fca_pro_check or run_gdpr_pro_check, so it misses explicit exclusions.

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?

There are no annotations, so the description carries the full burden. It says 'self-audit' which implies a read-only operation, and the URL parameter description discloses server-side fetching with SSRF guards. However, the main description does not explicitly state side effects (e.g., no data storage, no modifications), output format, or rate limits, leaving some ambiguity about how the tool behaves.

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 two concise sentences. The first sentence front-loads the action and scope; the second provides the regulatory context. No fluff 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?

The description explains the tool's purpose and regulatory focus but does not mention what the output looks like (no output schema is provided). For a compliance audit tool, an agent needs to know what the tool returns (e.g., violation list, pass/fail). It also omits mention of the tool's read-only nature as a general behavior. Overall, adequate for selection but not 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?

The schema has 100% coverage with descriptive parameter explanations, including examples for text and an enum-like list for asset_type. The main description does not add parameter detail, but the schema already provides sufficient semantics, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Run') and identifies the exact resource ('SEC retail communications self-audit') with scope ('US-touching crypto marketing'). It lists concrete regulatory topics (FINRA Rule 2210, anti-fraud, Reg BI) that clearly distinguish it from sibling jurisdiction-specific checks like run_fca_pro_check and run_mas_pro_check.

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 a clear usage context: 'for US-touching crypto marketing.' This implies when to use it versus other pro checks, but it does not explicitly mention alternatives or exclusions (e.g., 'use run_fca_pro_check for UK'). Still, the jurisdiction framing is clear enough for an agent to select it appropriately.

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 explaining behavior. It states the tool 'Returns a per-market launch-readiness verdict, per-rule analysis, and concrete rewrites,' which clarifies the output. However, it does not disclose whether the tool performs any writes, makes external requests, or requires special permissions. The audit nature implies read-only, but this is not explicitly stated.

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 two sentences, front-loaded with the core action and scope. It lists jurisdictions and launch surfaces without unnecessary fluff, and every phrase contributes meaning. It is concise and well-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?

Given the tool's complexity, the description covers the key elements: purpose, jurisdictions, 28 rules, launch surfaces, and return values. It does not mention how to provide input (URL vs. text) or the need for at least one input, but the schema descriptions handle that. The absence of an output schema is compensated by the explicit statement of returns, making the description complete for an overview.

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 100% for all parameters, so the baseline is 3. The description adds context about launch surfaces (e.g., landing page, KOL brief) that partially aligns with the asset_type parameter, but it does not materially enhance understanding of the individual parameters beyond what the schema already provides. The schema handles parameter semantics adequately.

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 clearly states a specific action: 'Run the full TGE / token-launch marketing readiness audit (28 rules)' and enumerates the jurisdictions and launch surfaces. This distinguishes it from sibling tools that focus on single jurisdictions or specific check types, making the tool's purpose unmistakable.

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 clear context on when to use this tool: for a comprehensive multi-jurisdiction TGE marketing audit across specified launch surfaces. It implies the tool is the combined audit compared to single-jurisdiction siblings, but it does not explicitly state exclusions or name alternatives, stopping short of a full guideline.

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 transparency burden. It adds useful context about audit scope (35–40 rules, specific rulebook topics) but omits behavioral details like whether the tool returns a report, is read-only, or has any side effects.

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, tightly worded sentence that front-loads the core purpose and includes a parenthetical rule count. No redundant or filler 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?

The description explains what the audit covers but leaves critical usage details unspecified: it does not clarify that at least one of url or text is typically required, nor does it describe what the tool returns (e.g., pass/fail, detailed report). Given the complexity of a 35–40 rule audit and the absence of an output schema, this is a significant 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?

The input schema has 100% parameter description coverage, so the baseline is 3. The description does not add additional meaning beyond what the schema already provides for url, text, and asset_type.

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 clearly states the tool runs a specific VARA Dubai marketing self-audit with a rule count and mentions key topic areas. This distinguishes it from sibling tools like run_fca_pro_check or run_ad_creative_check by naming the regulator and 'full audit' scope.

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 'full VARA Dubai marketing self-audit' implies use for VARA compliance checks, but the description does not explicitly state when to choose this over alternatives like run_ad_creative_check or other regulator-specific tools. Sibling names signal alternatives, but no active guidance is provided.

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 for behavioral disclosure. It indicates a text-search operation but does not disclose return format, result limits, pagination, or whether the operation is read-only beyond the inherent nature of a search.

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, front-loaded sentence with no filler words. Every part contributes to defining the tool's purpose and scope.

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 tool is simple with only two parameters, but there is no output schema and no annotations. The description covers the search action and scope but neglects to state that it returns matching signals or any details about the response, leaving an agent to infer the return 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 description coverage is 100% for both query and days parameters. The tool description adds context about searching across signal categories but does not elaborate on parameter syntax or behavior beyond the schema, so it meets the baseline without adding significant value.

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 action ('Text-search') on a defined resource ('NorthPoint's signal feed') and scopes the search to 'competitor/regulatory/narrative entries.' This clearly distinguishes it from siblings like get_latest_signal, which retrieves rather than searches.

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 when to use the tool—when a keyword or phrase needs to be found in the signal feed. However, it does not explicitly state when not to use it or mention alternative tools, so it lacks the full exclusion/alternative guidance.

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