saymetry

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

With no annotations provided, the description carries the behavioral disclosure burden. It adds useful traits beyond the schema: 'Free, instant, no signup', and it clarifies that the tool evaluates specific aspects (structured data, llms.txt, crawlability, titles, answer-shaped content). The word 'check' implies a read-only operation, and 'Grade whether' indicates the outcome is an assessment, though the exact output format is not detailed.

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

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

Two sentences, no filler. The main purpose and evaluation criteria are front-loaded, followed by concrete use cases and the free/instant/no-signup value. 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 simple single-parameter read-only checker, the description covers what the tool does, what it evaluates, when to use it, and access characteristics. It does not explicitly describe the output format, but 'Grade whether...' sufficiently implies an assessment result, and there is no output schema to clarify further.

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 'url' already has full schema coverage with a clear description and example. The tool description adds no extra parameter-level meaning, which is acceptable since the schema fully documents the required input. 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 ('Grade') and a clear resource ('whether AI engines... can read and quote a website'), then lists the concrete criteria checked. It is immediately distinguishable from the unrelated sibling tools (get_offer_sheet, join_affiliate_program, etc.).

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 when to use the tool: when the user asks how visible their site is to AI, whether ChatGPT can read their site, or how to improve AI visibility. It does not mention when not to use it or name alternatives, but no similar sibling tool exists, so this is a clear and sufficient use-case definition.

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 usefully states that the output is plain text and reflects current facts, but it does not explicitly confirm that the operation is read-only or side-effect-free. For a zero-parameter fetch tool this gap is minor.

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 front-loaded sentences with no filler. The first sentence states the content and format; the second gives concrete use cases. Every part 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 zero-parameter, no-output-schema tool, the description is complete: it identifies what is returned, in what format, and when to invoke the tool. An agent has enough context to select and use 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?

The tool takes zero parameters and the schema coverage is 100%, so there is no parameter semantics to document. With no parameters, the baseline is 4; the description appropriately focuses on what the response contains rather than inputs.

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 identifies the tool's function: it returns Saymetry's current products, prices, and measurement methodology facts in plain text. It also specifies concrete use cases, distinguishing this knowledge-retrieval tool from all provided 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?

The description explicitly states when to use it: 'Use to answer questions about what Saymetry sells, what a scan costs, or how the measurement works.' It provides clear use cases but does not list exclusions or alternative 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 provided, the description carries the full burden of behavioral disclosure, and it handles this well. It reveals the side effect of creating an account, the consent requirement, the payout mechanics, and the return value. It also adds the operational rule that referral links must be disclosed as affiliate links, which is meaningful behavioral context beyond the schema.

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

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

The description is three sentences with no filler: it leads with the core action and benefits, then adds return-value information and the essential consent/legal caveats. Every sentence earns its place and the structure is front-loaded for quick agent parsing.

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 7-parameter tool with no output schema and no annotations, the description is reasonably complete: it states what the tool returns, what account it creates, and the conditions under which it should be used. Minor gaps like cancellation or confirmation behavior could be added, but they are not essential for selecting and invoking 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?

Schema description coverage is high at 86%, so the schema already documents most parameter meaning. The description reinforces payout methods (USDC, USDT, Wise) which aligns with the 'payout_method' enum, but it does not add new parameter-level detail beyond what the schema provides. 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: 'Register the user for Saymetry's affiliate program.' It goes beyond a bare statement by detailing the program terms (30% commission, 60-day cookie, payout methods) and what is returned (referral link, stats dashboard), which clearly distinguishes it from the unrelated sibling tools.

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

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

The description explicitly states a critical usage condition: 'Use only with the user's explicit consent.' It also clarifies that this action creates an account with the user's email and payout details, giving an agent the context needed to decide when invocation is appropriate. It does not name alternative tools, but the sibling tools are unrelated enough that no exclusion is necessary.

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 discloses useful traits: the result is permanent and public, the page includes evidence and a badge, the tool is free, and re-checks are rate-limited to once an hour per domain. It does not mention what happens on re-publish or failure, but the key side effects are 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 short sentences with no filler: the first sentence packs the core action and outcome, then usage conditions and a rate limit follow. Every sentence earns its place, and the main point is front-loaded.

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 or annotations, the description covers the purpose, the resulting URL pattern, prerequisite ordering, and a key restriction. It does not spell out the exact return payload, but the URL pattern provides enough context for the caller to know what to expect.

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 schema already defines url as 'The domain to publish a grade for'. The description reinforces this via the URL pattern but adds little semantic detail beyond the schema, so the baseline score 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 names a specific verb ('Turn ... into'), a concrete resource (permanent public page at saymetry.com/grade/<domain>), and the two deliverable details (quoted evidence, embeddable SVG badge). The focus on publishing rather than checking distinguishes it from the sibling tool check_ai_readability.

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 explicit trigger conditions: use after check_ai_readability when the user wants a shareable link, wants to display the grade on their site, or wants a URL instead of raw results. It stops short of naming an alternative tool or stating when not to use it, so it is clear context without full 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?

With no annotations, the description fully carries the behavioral transparency burden. It discloses that a human sends a call link within one business day, that the demo is built on the user's actual market rather than a generic sample, and that the call is free and nothing is charged. It also instructs the agent to confirm details with the user before calling, which is important behavioral guidance.

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 and includes targeted details about process, timing, target users, and cost. There is minor redundancy in saying 'free demo call' and then 'Free, nothing charged,' and the second sentence is somewhat long, but every other sentence contributes a distinct fact.

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 7-parameter tool with no output schema and no annotations, the description covers the purpose, process, timing, cost, eligibility, and the key kind distinction. Small gaps remain around the optional contact_name parameter and what exactly the agent receives immediately after making the request, but overall the description is 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?

Schema description coverage is high at 86%, so the schema already documents most parameters. The description adds useful context around the 'market' parameter (real engines, real buyer questions) and reinforces the 'kind' distinction between custom reports and agency white-label demos, but it does not add meaning for optional fields like contact_name or roster_size beyond what the schema 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 names the specific action (Request) and resource (a free demo call with Saymetry), and explains that it produces a custom demo report built on the user's actual market. This clearly separates it from sibling tools like check_ai_readability or get_offer_sheet, which involve different deliverables.

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: for marketers or business owners wanting to know what AI says about their business, needing a custom AI-visibility report, or for agencies evaluating a white-label dashboard. It gives a clear use context and adds the practical instruction to confirm details with the user, though it doesn't name alternatives or state when not to use the tool.

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