Sellular

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 clearly discloses partial results with per-domain errors instead of whole-batch failure, rate-limiter debit once per domain, and 24-hour caching per domain. These are exactly the behavioral traits an agent needs before invoking the 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?

Four sentences with no filler: purpose and outputs, failure behavior, rate-limit/cache cost, and use case. The most important facts are front-loaded in the opening clause, and every sentence contributes new information.

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

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

With no output schema and no annotations, the description supplies the essential return fields, error behavior, and operational costs an agent needs to call the tool and interpret results. It is sufficiently complete for a single-parameter batch 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 100%, so the schema already documents the domains array, its bounds, item type, and URL acceptance. The description adds the 'public domains' scope and per-domain evaluation semantics, but does not meaningfully go beyond what the schema already provides.

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

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

The description opens with a specific verb and resource: scanning up to 10 public domains in one call, then enumerates the concrete outputs (visibility score 0-100/A-F, llms.txt existence, directory opportunities). The 'bulk' framing and 'up to 10' clearly distinguish it from singular sibling tools like scan_domain even though no sibling is 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?

It gives an explicit when-to-use context: 'Use for outreach research across a prospect list.' It implies single-domain scans would belong elsewhere, but it does not name an alternative or state when not to use it, so it falls just short of full 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 burden and does well: it declares 'Read-only,' requires the MCP_API_KEY bearer token, and describes the output structure (present/derived/missing with fixes, deduped blockers, progress). It doesn't mention rate limits or error handling, but for a read-only check tool this is minor. The 'without generating a full kit' also prevents the agent from expecting 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-loaded with the main purpose and the key differentiator ('WITHOUT generating a full kit'), then details output, safety, auth, and usage. Every sentence earns its place; there is no fluff or repetition.

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 no annotations and no output schema, the description covers the tool's purpose, output details, auth requirement, and explicit usage guidance. It doesn't specify error scenarios or edge cases (e.g., what if no products exist), but for a read-only check it is thorough enough for an agent to call correctly. The differentiation from generate_submission_kit is a strong point.

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

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

Schema coverage is 100%, so each parameter (limit, product, directory_name) already has a descriptive schema entry. The tool description adds no new parameter-level meaning beyond that, but it does not need to since the schema is complete. This matches the baseline of 3 for high schema coverage.

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

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

The description uses a specific verb ('Check what is missing') and a clear resource (fields required for submission), and explicitly contrasts with generating a full kit, which distinguishes it from generate_submission_kit. It also lists the output components (per-directory status, derived sources, blockers, progress), leaving no ambiguity about its function.

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 states when to use it: 'Use to answer "what is missing" or "where should submissions start" before doing any submission work.' It also implies the alternative by saying 'WITHOUT generating a full kit,' which clearly tells the agent this tool is not for producing the submission kit itself. No exclusions are missing.

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 explains the output (rank, grade, strengths/weaknesses) but does not disclose whether it is read-only or any side effects. Since it's a comparison/analysis tool, it's likely non-destructive, but that 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?

Two sentences, front-loaded with the primary action and output. Every word adds value, 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?

Given no output schema, the description adequately conveys the result format (ranked list with grades and strengths/weaknesses). It does not cover error cases or rate limits, but for a simple one-parameter tool it is sufficiently complete for an agent to invoke 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 100% for the single parameter 'urls' with a clear description. The tool description adds context about purpose but no additional parameter semantics beyond what the schema provides. Baseline 3 applies due to high coverage.

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

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

Description clearly states the tool scores 2-5 public websites and ranks them by visibility, with a specific verb (score, rank) and resource (websites). It distinguishes from siblings like get_visibility_score (single site) and seo_audit_summary by focusing on comparison.

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 states 'Use to benchmark a site against competitors and explain who wins and why,' giving clear context for when to invoke. Does not name alternative tools explicitly but the purpose is unambiguous enough for an agent to select correctly.

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 explaining behavior. It clarifies that the tool returns text to serve at /llms.txt, is built from fetched metadata, and does not itself write the file (instructing the agent to do so). It does not cover failure modes or network behavior, but the non-mutating boundary is reasonably 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?

The description is front-loaded with the core purpose, then return value, then conditional repo-writing guidance, then usage trigger. Every sentence contributes useful information, though the in-repo instruction makes it somewhat dense for a single-purpose 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 simple one-parameter tool with no output schema, the description adequately explains the return value, the trigger condition, and post-generation handling. It could be more explicit about what 'Key Pages' contains or what happens on invalid URLs, but those are minor gaps given 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 already fully documents the only parameter (url) with accepted forms ('A domain (example.com) or full URL'). The description adds no new parameter-level detail beyond 'fetched metadata,' so with 100% schema coverage 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 states a specific verb ('Generate'), a specific resource ('llms.txt file body'), and the domain purpose ('AI-discoverability manifest'). It clearly distinguishes itself from sibling generators like generate_review or generate_seo_fixes by naming the exact artifact produced.

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

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

It gives an explicit trigger: 'Use when a site fails the llms.txt check and the user wants one made.' It also adds practical conditional guidance about writing the file in a repository. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a full when/when-not explanation.

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 fully carries the behavioral burden. It discloses that the article is never published, goes to an editor for approval, requires a paid plan and quota, supports auth via product API key or admin key, and explains side effects of brief_only and hold_as_draft.

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?

Although long, the description is appropriately sized for a complex tool with nine parameters and multiple workflows. It is front-loaded with the core purpose and uses clear all-caps section markers like TO WRITE THE ARTICLE YOURSELF and TO DRAFT WITHOUT SUBMITTING to organize dense but necessary 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?

Given the tool's complexity, lack of output schema, and interconnected parameters, the description is remarkably complete. It covers auth, quota, editor approval, draft holding, custom rivals, research extraction, comparison table control, and the return artifact (preview link and editor name).

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds substantial meaning beyond the schema: it explains the product_url matching rules, the brief_only-to-draft flow, the research JSON pass-back mechanism, the fills semantics, and the quota implications of hold_as_draft.

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: generating a competitor review article for an app identified by product_url or id. It clearly distinguishes itself from sibling tools like generate_seo_fixes and list_my_reviews by describing the article generation workflow and editor hand-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 provides detailed usage modes: normal generation, brief_only followed by draft, hold_as_draft, and auth requirements. It explains when to use these modes and their consequences, though it does not explicitly contrast with sibling tools or list exclusion criteria.

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 so well: it discloses that the tool is read-only on Sellular's side and writes nothing itself. It also clarifies that the agent is expected to apply the generated fixes manually, though it does not describe the response format or any rate-limit 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?

The description is dense but every sentence earns its place: purpose and deliverables are front-loaded, the target user and workflow are stated, and the alternative tool is called out. No filler or redundant restatement of the tool name exists.

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 one parameter and no output schema, the description explains the deliverable content, where files belong in the source tree, the intended workflow, and the read-only behavior. It could be more explicit about the exact response shape, but the agent has enough context to invoke 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 coverage is 100% and the url parameter already has a clear description ('A domain (example.com) or full URL to build fixes for'). The tool description adds the qualifier that the site must be public and that fixes target failing checks, but it does not need to add more 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 names a specific action and resource: turn a public site's failing SEO/AI-discoverability checks into ready-to-apply fixes, with concrete deliverables like robots.txt, sitemap.xml, and head snippets. It also differentiates from the sibling seo_audit_summary by noting that summary is for diagnosis only.

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

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

It explicitly states the intended context: coding agents inside the site's own repository who will write files, insert snippets, and deploy. It also gives a clear alternative condition: run seo_audit_summary first when only the diagnosis is wanted, making the when-to-use decision unambiguous.

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, so the description carries the full behavioral disclosure burden. It explicitly states the tool is read-only and has no side effects, requires the MCP_API_KEY bearer token, and clarifies the output contract (`fields`/`copyText` are pasteable; `requirements` holds prep instructions). This is substantial non-obvious context.

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 longer than average, but every sentence contributes critical operational information: output contents, field separation, read-only guarantee, auth requirement, and intended use case. It is dense yet free of filler, warranting above-average structure score.

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 summarizing the output contract: pasteable fields, prep instructions, blockers, and progress. Combined with fully described schema parameters and a clear side-effect profile, an agent has enough information to call the tool correctly without dashboard context.

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% description coverage across all six parameters, including rich explanations for `automation`, `signed_out`, and `remaining_only`. The description itself adds no parameter-specific meaning beyond the overall product scope, so 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 opens with a specific verb and resource: 'Build ready-to-paste directory submission copy' for a product, then enumerates the concrete contents. It also explicitly distinguishes itself from submission tools by stating 'it does NOT submit anything anywhere,' which sets it apart from sibling record_submission.

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

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

It gives an explicit call-to-use: 'Use when preparing directory submissions without opening the dashboard.' The read-only statement implies not for actually submitting, but it does not name an alternative sibling or state a when-not-to-use condition. This is clear context without being a fully explicit routing statement.

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 to rely on, the description carries the full burden and excels: it discloses that the tool has no side effects, requires MCP_API_KEY bearer auth, auto-upgrades badge tiers, resolves links dynamically, and warns not to pin a width. This is substantial behavioral context beyond the basic operation.

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?

Though longer than average, it is densely packed: purpose, output formats, dynamic tiering, link behavior, integration responsibility, and auth are all covered with no filler. The core purpose is front-loaded, and 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 one-parameter tool with no annotations and no output schema, the description is remarkably complete: it states what is returned, how to use the result, what the badge dynamically does, and what credentials are required. Nothing essential for correct invocation 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?

The input schema already documents the single optional 'product' parameter well (name/domain, substring match, optional when one active product), so the baseline is 3. The description adds contextual framing about per-product embeds and tier behavior, but it does not materially extend the parameter protocol.

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 ('Get'), a unique resource ('Sellular badge embed'), the target (connected account's products), and the output formats (HTML/JSX and Markdown). This clearly distinguishes it from the sibling SEO and analytics tools without needing to name them.

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

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

It gives clear practical guidance: the tool edits nothing, and the caller should either paste the snippet into the product repo themselves or hand it to a developer. It also notes the account-scoped auth requirement. It does not explicitly single out alternatives or state when not to use it, but the context makes its use case apparent.

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 read-only semantics, account scoping, and the required MCP_API_KEY bearer token. It also describes the output metrics, reducing ambiguity about 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?

Three compact sentences with no filler: purpose, scope/behavior, and usage trigger all appear in order. Every sentence earns its place.

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

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

For a single optional parameter and no output schema, the description tells the agent what it returns, when to use it, and what auth is needed. There are no meaningful gaps 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 100%, so the product parameter is already well documented there. The description adds some context by tying the product to the connected account, but most meaning lives in the schema, making baseline 3 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 names a specific verb and resource ('Get visitor analytics for one of the connected account's products') and enumerates the exact metrics returned. It is clearly distinct from siblings like get_visibility_score, which cover a different facet.

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 when asked how a tracked product's traffic is doing,' which gives clear invocation guidance. It does not name alternatives or negative conditions, so it stops short of full when-not-to-use clarity.

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 what the score measures (meta tags, sitemap, llms.txt, structured data) and the output grade, which is useful. However, it does not explain behavior for invalid URLs, non-public sites, rate limits, or whether it is a fast lookup versus a live scan.

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 concise sentences front-load the action and result, include the scoring scale and measurement signals, and end with a usage directive. Every sentence contributes meaning with no 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?

For a one-parameter tool with no output schema, the description covers the key facts: input, output range, grading, measured signals, and typical use case. It does not describe the exact response shape, but that is less critical given the simple nature of the 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?

The schema already fully documents the single parameter (url) with a clear description of domain or full URL. The tool description adds no new parameter semantics beyond restating 'domain or URL,' so the baseline 3 applies.

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

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

The description names a specific resource (Sellular visibility score), a concrete output (0-100, A-F), and the input type (domain or URL). It is clear and distinct from the sibling tools by focusing on the visibility score rather than a full scan or audit summary, though it does not explicitly reference a sibling to differentiate.

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 states when to use the tool: 'Use when asked how discoverable or SEO-ready a site is.' It provides clear context for the agent, but does not mention exclusions or alternatives such as seo_audit_summary or compare_visibility, leaving some routing ambiguity.

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 clearly states the operation is read-only, reference data only, and does not submit anything, while also disclosing the sort order. This is strong for a simple list tool, though it does not mention pagination or limit behavior explicitly.

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

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

Three tight sentences, each earning its place: the first defines the core operation and sort, the second establishes read-only safety, and the third gives the use case. No filler or redundant restating of the tool name.

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

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

For a simple read-only reference tool with only two optional parameters, the description covers what the tool does, its filter behavior, and its intended use. It does not describe the return shape or enumerate valid category values, but given the absence of an output schema and the open-ended string category, the description is largely sufficient 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?

The schema describes only the category parameter, leaving limit undocumented (50% coverage). The description compensates for category by explaining its purpose and giving examples, but it says nothing about limit, its default, or its bounds, so an agent gets only partial parameter guidance.

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 ('List'), names a concrete resource ('curated directories a product can submit to'), and adds a distinguishing feature ('sorted by domain authority'). It clearly differentiates from sibling tools like list_public_listings and list_tracked_sites by focusing on submission-worthy curated directories.

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 states the intended use case ('Use to suggest where a product should get listed') and includes a clear exclusion ('this does NOT submit anything'). It does not name alternative tools or explicitly say when not to use it, but the context 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?

No annotations are provided, so the description carries the full burden. It discloses the ordering (newest first), the output fields (status, editor notes, public URL), and the account-wide scope. It also explains authentication nuances. It does not explicitly state that it is a read-only operation, but that is implied by 'list'. It also does not mention pagination or rate limits, but these are minor for a simple list tool. The description is transparent about the key behaviors an agent needs to know.

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 primary action and scope, followed by usage and authentication details. Every clause adds value: the list of statuses, the note about editor notes and URL, and the authentication guidance. There is no redundancy or filler. The structure efficiently communicates the tool's purpose and key behavioral nuances.

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 list tool with 2 optional parameters and no output schema, the description covers the essential aspects: what is listed, the ordering, the included fields, and the authentication requirement. It does not describe the exact response format, but since no output schema is provided, the description's mention of status, editor notes, and public URL gives sufficient context. It also lacks explicit mention of pagination, but the 'limit' parameter implies it. Overall, the description is sufficiently complete for an agent to call the tool 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?

The schema description coverage is 50%: the 'status' parameter has a description and enum, while 'limit' has no description but has default/min/max constraints. The tool description does not mention either parameter or add any additional meaning beyond the schema. For instance, it doesn't explain the effect of 'limit' or how 'status' filtering works. Since coverage is exactly 50%, the description should compensate for the undocumented 'limit' parameter, but it doesn't. Therefore, a score of 3 is appropriate – the schema provides baseline info, but the description adds no parameter guidance.

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 verb 'List', the resource 'review articles', the scope 'across every product you own', and the ordering 'newest first'. It also specifies the included fields (editorial status, editor notes, public URL) and the intended use case ('check what happened to a generated review'). This clearly distinguishes it from sibling tools like list_directory_listings or list_public_listings, which target different resources.

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 a clear use case: 'Use to check what happened to a generated review.' It also explains authentication requirements (product API key or admin key) and notes that both list the whole account. While it doesn't explicitly contrast with alternatives, the specificity of the purpose and the absence of a similar sibling tool make the usage context clear. It could be improved by explicitly stating when NOT to use it, but the guidance is sufficient.

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 behavioral disclosure burden. It adds a meaningful 'Read-only' signal, which is valuable, but it does not describe return format, pagination, or how the search/category filters behave. Behavioral 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 short, purposeful sentences. The core action and filters are front-loaded, and the read-only note and use-case add value without 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 definition is adequate for a simple browse tool, but it is incomplete: there is no output schema, so the return format is left to inference; the category parameter is unexplained; and the overlap with sibling list_directory_listings is not addressed.

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

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

Schema description coverage is only 33%, with only the search parameter described. The description repeats that category and search are optional filters but adds no detail about category values, limit behavior, or filter semantics. It 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?

The description clearly states the action ('List'), the resource ('public community listings on Sellular'), and the optional filters ('category or search'). It is specific and understandable, but it does not explicitly differentiate from the similarly named sibling list_directory_listings, 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?

It explicitly gives a use case ('Use to browse products already listed in the community directory') and notes the operation is read-only. It does not mention when not to use it or name alternatives, but the intended context is clear.

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 supplied, so the description carries the full burden. It discloses read-only behavior, account scoping, and authentication prerequisites, which is valuable context beyond what the empty schema provides. It does not mention pagination, response shape, or failure behavior, which prevents a higher score.

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 with no filler: the action and resource are front-loaded, followed by useful scoping and auth details. Every sentence contributes value without 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?

For a zero-parameter account-scoped listing tool, the description covers purpose, returned fields, read-only nature, and setup prerequisites. It lacks an explicit output schema description or mention of pagination/limits, but the core information needed to call it correctly is present.

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 is empty with 0 parameters and schema description coverage is 100%, so there are no parameter semantics to clarify. The zero-parameter baseline of 4 applies, and the description's context about account scoping and auth explains why no arguments are 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?

States a specific verb ('List'), a clear resource ('sites/products tracked on the connected Sellular account'), and enumerates the returned aspects: type, category, status, and Sellular badge verification. The 'Account-scoped' phrasing differentiates it from sibling list tools such as list_public_listings and list_directory_listings.

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?

Provides clear context by noting that the operation is account-scoped, read-only, and requires MCP_API_KEY and MCP_ACCOUNT_EMAIL to be configured. However, it does not explicitly tell the agent when to prefer this tool over sibling listing tools or when not to use it, leaving routing to be inferred.

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

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

With no annotations provided, the description carries the full behavioral burden and handles it thoroughly. It discloses idempotency ('recording the same directory again updates that record rather than adding another'), the fact that nothing is ever deleted, authentication requirements (MCP_API_KEY bearer token), the confirmation-before-writing behavior, and the three status semantics. This goes well beyond a typical terse mutation description.

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 compact paragraph with no filler. Each sentence earns its place: core side effect, status semantics, optional inputs, idempotency, non-submission clarification, and auth/confirmation prerequisite. It is front-loaded with the most decision-relevant information and remains readable despite its density.

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 mutation tool with five parameters, no annotations, and no output schema, the description is unusually complete. It covers purpose, side effects, idempotency, deletion behavior, authentication, confirmation, status meanings, and integration with sibling tools. Nothing essential to deciding whether and how to call this tool 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 100%, so the schema already documents every parameter fully. The description restates status values and optional URL/note only at a high level. It adds one useful behavioral constraint tied to a parameter ('Idempotent per product+directory'), but it does not significantly augment the per-parameter meanings beyond what the input schema already provides.

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 precise verb and resource: 'Record that one of your tracked products has been submitted to a directory.' It also explains the downstream effect on sibling tools ('so check_submission_readiness and generate_submission_kit stop listing it as remaining') and explicitly distinguishes what it does not do ('This does NOT submit anything anywhere'). This makes the tool's purpose unmistakable and well differentiated.

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 clear when-to-use context: after a submission has happened, to prevent duplicate resubmission. It also provides a when-not-to-use boundary ('does NOT submit anything anywhere'), and explicitly ties the tool's effect to check_submission_readiness and generate_submission_kit. This is sufficient guidance for an agent to choose it over related tracking 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. It discloses read-only behavior and 24-hour caching, and clarifies that directory listings are 'submission opportunities, not verified absences,' preventing misinterpretation. It doesn't mention rate limits or auth, but for a read-only audit tool this is adequate.

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 tightly packed sentence with a colon leading into a list of outputs. Purpose is front-loaded, usage guidance comes at the end, and there is zero 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?

The description lists all major outputs and notes caching, which is essential for an agent deciding to call it. It doesn't specify exact response formats, but without an output schema and with only one input parameter, the essentials are covered. The 'submission opportunities' caveat adds important nuance.

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 parameter 'domain' is fully documented in the schema (100% coverage) with 'A domain (example.com) or full URL to scan.' The description doesn't add meaning beyond that, but since schema coverage is complete, 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 states a specific verb ('audit') and resource ('public website'), and enumerates concrete outputs (visibility score, llms.txt presence, directories, competitor). It clearly distinguishes itself from siblings like get_visibility_score (single score) and seo_audit_summary (broader SEO) by framing it as a 'one-call visibility 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?

It explicitly says 'Use when asked to audit or size up a site's overall discoverability in one shot,' giving clear context. It doesn't name alternative tools for different scenarios, but the phrasing implies it's the go-to for quick audits, leaving some ambiguity about when not to use 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 of behavioral disclosure. It explicitly declares 'read-only' (the safety profile) and discloses output ordering behavior: 'failures sorted by impact (biggest score wins first)'. It does not mention rate limits or behavior on unreachable/invalid URLs, a minor gap for a network-dependent audit 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?

Three sentences, each earning its place: function, return contents plus sorting rationale, and usage sequencing. The core purpose is front-loaded and there is zero 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 one-parameter tool with no output schema and no annotations, the description covers the essentials: what it does, that it is safe (read-only), what it returns (passing/failing checks with impact-sorted failures), and the typical invocation sequence. Minor omissions are error handling for unreachable URLs and any rate-limit caveat, but nothing an agent needs to invoke 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?

The schema already covers the single url parameter at 100%, so the baseline is 3. The description adds a genuine semantic constraint beyond the schema by calling the URL 'public', signaling that internal or non-publicly-addressable URLs are out of scope. It also frames the operation as auditable content rather than just a URL string.

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: 'Run a read-only SEO / AI-discoverability audit on a public URL', and specifies the observable outcome ('Returns the passing and failing checks'). It also differentiates from the closest sibling by naming get_visibility_score as a predecessor, so an agent can tell this tool apart from a score-only tool without opening the schema.

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

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

The final sentence gives explicit invocation context: 'Use after get_visibility_score to explain a low score', which tells the agent when this tool fits in a workflow. However, there is no when-not guidance or comparison against other audit-adjacent siblings like scan_domain or bulk_scan, so it stops short of a 5.

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 idempotency, the update-instead-of-duplicate behavior, that it never deletes anything, the need for MCP_API_KEY bearer token, and the confirmation-before-write requirement. This is comprehensive and leaves no hidden side effects unaddressed.

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 dense but every sentence earns its place: primary purpose, dependent tools, idempotency/update behavior, safety, auth, confirmation, and usage trigger. It is front-loaded with the core action and progressively adds context. No filler.

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

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

The description covers purpose, usage, side effects, and auth, and the schema documents all parameters. The only gap is the lack of any mention of the return value or response format, which could matter to an agent expecting a confirmation object. Still, for a mutation tool with rich context, this is a minor omission.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add parameter-specific guidance beyond the schema; however, the schema itself is detailed (e.g., 'tagline' notes 'under ~60 chars', 'description' notes it feeds directory copy). The description adds no extra param semantics, so a 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 opens with a specific verb and resource ('Start tracking one of your products on the connected Sellular account') and explicitly names the sibling tools that depend on it (check_submission_readiness, generate_submission_kit, etc.), distinguishing it from list_tracked_sites. It also clarifies the update semantics, leaving no ambiguity about what the tool does.

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

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

It gives an explicit usage condition: 'Use when a product is missing from list_tracked_sites.' It also explains the idempotent retry behavior and the prerequisite of a bearer token, and implicitly differentiates from list_tracked_sites (which lists) and the other account-scoped tools (which require prior tracking).

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