Incisory

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

No annotations exist, so description carries full burden. It discloses that data covers last 30 days and includes a snippet, but does not mention permissions, rate limits, or behavior when no data is available. Adequate but could be more transparent.

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?

Single sentence conveys two key functions (display data and provide snippet). Could be restructured into two sentences for clarity, but overall concise with minimal waste.

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 and 0% schema coverage, the description is somewhat complete for a simple tool, but lacks parameter details and return format. It adequately covers the main purpose but leaves 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 has 0% description coverage for parameters 'days' and 'token'. The description does not explain these parameters, only mentions 'last 30 days' which loosely relates to 'days' but not explicitly. 'token' is entirely unexplained, leaving the agent guessing.

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 shows AI assistant visits, value (last 30 days), and provides a tracking snippet. It distinguishes itself from sibling tools like google_data or audit_visibility by being specific to AI traffic.

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?

Description implies usage for viewing AI traffic and obtaining the snippet, but does not explicitly contrast with alternatives or provide when-to-use/not-use guidance. Sibling tools are diverse, making the lack of explicit guidance a gap.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool reads the site, queries multiple AI models, and takes ~60 seconds. It does not mention permissions or rate limits, but the behavior is adequately transparent for a read-only analysis 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?

The description is moderately long but front-loaded with the core action. Every sentence provides useful context (website input, analysis methods, output components, time). Minor redundancy in explaining the process could be tightened.

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 fully explains what the audit returns: visibility percentage, verbatim answers, AI recommendations, and three fastest fixes. Combined with the time estimate and process steps, it gives the agent a complete mental model.

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%, but the description adds meaning beyond schema by explaining the function of each parameter: website is required, niche is 'what it sells + who for + where', and business is optional to override inference. This helps agents understand parameter intent.

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 an AI-visibility audit for a business with specific details: reads the website, contacts AI models, returns visibility percentage, verbatim answers, competitor recommendations, and fixes. This distinguishes it from siblings like ai_traffic or my_visibility.

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 by saying 'Pass just its website', but does not explicitly state when to use this tool versus alternatives like ai_traffic or get_audit. No when-not-to-use 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 must convey behavioral traits. It mentions the scan checks claims and provides a fix, but does not explicitly confirm that it is read-only or detail any side effects. It adds context about frequency and plan restriction, but lacks full transparency.

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 extremely concise at two sentences, front-loading the purpose and adding relevant details about the scan's scope and schedule. Every word adds value.

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?

While the description explains the tool's function and frequency, it lacks details about the output format or structure. Given no output schema, the description should hint at what the agent can expect, but it only mentions categories of claims and a fix.

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

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

There is one parameter 'token' with 0% schema description coverage. The description does not mention the parameter or its purpose, leaving the agent without guidance on what value to provide. This fails to add 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 clearly states the tool performs a brand-accuracy scan, checking AI statements about the business against the real web and providing a fix. It distinguishes itself from siblings like 'audit_visibility' by specifying the brand focus and claim verification.

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 periodic brand checks, mentioning it runs weekly on the Engine plan. However, it does not explicitly state when to use this tool versus alternatives or when not to use it, leaving some 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?

No annotations provided, so description is the sole source. It states the tool lists work over N days but doesn't disclose if it's read-only, requires permissions, or any side effects. 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?

Single sentence with clear structure. Includes examples for clarity. No wasted words, well 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?

With 2 params, no output schema, and no annotations, the description covers the basic purpose and time range. However, it lacks detail on return format and scope disambiguation among 17 sibling tools.

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

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

Schema coverage is 0%. Description explains 'days' parameter ('over the last N days') but fails to mention 'token' parameter at all. Only one of two parameters gets contextual meaning.

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 uses specific verb 'List' and resource 'automated work' with examples (scans, articles, Reddit threads). It distinguishes from siblings by being a changelog of all automated actions, but could be confused with other listing 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?

No explicit guidance on when to use this tool versus alternatives like list_content_queue or list_reddit_queue. The description implies a summary use case but doesn't provide exclusions or comparisons.

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 burden. It states that the tool shows a prioritized list and mentions 'uses your latest scan', but it does not disclose behavioral details such as authentication requirements, rate limits, or what happens to existing scans. The transparency is adequate but not deep.

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 long, front-loaded with the core functionality, and contains no unnecessary words. Every sentence adds value.

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 4 optional parameters, no output schema, and no annotations, the description provides sufficient context to understand what the tool does and how to use it. It mentions a 'prioritized list' as the return value. Minor omission: it does not specify if the list is a JSON array or other format, but it is acceptable for a list 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?

With 0% schema description coverage, the description must compensate. It adds meaning by differentiating 'token' (for account scan) from 'business/website/niche' (for ad-hoc audit), but it does not describe each parameter individually or provide constraints like data format or required input.

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 specifically states the verb 'show', the resource 'third-party sources cited by ChatGPT/Gemini', and the condition 'where you were NOT named'. It clearly distinguishes from sibling tools like 'ai_traffic' or 'audit_visibility' which likely target different metrics.

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 guidance on two usage modes: using an account token for the latest scan, or passing business/website/niche for an ad-hoc audit. It is clear when to use each, but it does not explicitly mention when not to use the tool or compare it to 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?

No annotations are provided, so the description must cover behavioral traits. It states the tool runs weekly (implied batch or scheduled), but does not disclose read-only vs. destructive nature, authorization needs, or any side effects. The phrase 'the latest competitor decode' suggests it might be a report generation, but concrete behaviors are missing.

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 relatively short (two sentences) and focused, but the first sentence is a run-on that jumbles several concepts. It could be broken down for clarity without adding length.

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 should detail what the tool returns. It mentions 'why AI engines cite the top rival' and 'specific moves,' but does not describe the structure or format of the output, leaving the agent without enough information to handle the result 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 only parameter 'token' has no description in the schema, and the tool description does not mention it at all. With 0% schema description coverage, the description completely fails to explain what the token is or how to use 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 clearly states the tool provides competitive analysis on why a rival is cited instead of the user, including footprint and recommended moves. It differentiates from siblings like audit_visibility and brand_accuracy by focusing on competitor comparison, but it could be more specific about the output format.

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

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

No guidance on when to use this tool versus alternatives like citation_gap or audit_visibility. The only usage hint is 'Runs weekly on the Engine plan,' which implies scheduling but doesn't help an agent decide when to invoke 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?

With no annotations, the description must disclose key behaviors. It explicitly states replies are 'queued for human review, never auto-posted' and 'posting is your call,' which is clear and truthful about the tool's non-automation nature.

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 long, front-loading the core purpose and key constraint (no auto-posting). Every sentence adds value; there is no redundancy or filler.

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

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

While there is no output schema, the description adequately covers what the tool does and its key behavioral trait (human review requirement). It lacks details on return format or queue details, but for a search tool, the core functionality is well-communicated.

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 low (25%), so the description compensates by explaining the relationship between token and other parameters (niche, business, website). It clarifies that token is for account-queued results while the others are for ad-hoc searches, adding meaning beyond the bare 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 clearly states the tool 'searches for real, high-intent Reddit threads relevant to a business' and drafts replies. It distinguishes itself from sibling tools by focusing on Reddit thread discovery and reply drafting, a unique 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 explains how to use the tool: 'Use your account token, or pass business/website/niche directly for an ad-hoc search.' It provides two modes, giving implicit guidance on when each is appropriate, but does not explicitly compare with sibling tools like list_reddit_queue.

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 should disclose behavioral traits. It only states 'Fetch', implying a read operation, but does not confirm non-destructiveness, permissions, rate limits, or what the response contains.

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 sentence with 12 words, front-loading the core purpose. Every word is necessary and there is 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 simple fetch tool with one parameter and no output schema, the description is largely sufficient. It tells what it does and the source of the parameter, though it could mention the output briefly.

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 0% description coverage, so the description must add meaning. It clarifies that the 'id' parameter comes from the shareable result URL, which is helpful beyond the schema's type 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 clearly states the verb 'Fetch' and the resource 'audit', and specifies that the id comes from the shareable result URL. However, it does not explicitly differentiate from sibling tools like 'audit_visibility'.

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 when you have an id from a shareable result URL, but does not provide guidance on when to avoid using this tool or mention alternatives among siblings.

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

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

Description discloses use of account token and conditional behavior (if not connected, returns link). However, no annotations exist, and it doesn't cover error handling, idempotency, or whether it's read-only.

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

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

Three sentences with key information front-loaded. Some redundancy ('Real (not estimated)') could be trimmed, but overall efficient.

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

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

Given minimal structured data (1 param, no output schema, no annotations), description covers main points: what data, condition for connection, token usage. Missing return format and data field details.

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

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

Schema coverage is 0%, but description adds meaning by explaining the token parameter ('Uses your account token'), which the schema lacks. This provides essential context.

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 it provides real Google Search Console and GA4 data. The verb 'returns' is used, but it could be more explicit about fetching. It distinguishes from siblings by specifying the source (Google account).

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

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

No explicit guidance on when to use this tool versus alternatives like ai_traffic or my_visibility. It mentions behavior when not connected but lacks context for choosing this tool.

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 full burden. It only states it lists drafts for your account, but does not disclose read-only nature, authentication requirements, or other behavioral traits (e.g., pagination, limits).

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

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

One clear sentence with no extraneous information. The description is appropriately sized and front-loaded with the core function.

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 but the description omits explanation of the token parameter and does not mention return format or any side effects. Given no output schema, more detail would be needed for full 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?

The single parameter 'token' is undocumented in both schema and description. With 0% schema description coverage, the description fails to add any meaning about the parameter.

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

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

The title 'List content drafts' and description state it lists generated article drafts with title, target question, and status for the account. It clearly defines the resource and purpose, but does not explicitly differentiate from sibling tools like 'list_reddit_queue'.

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

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

No guidance on when to use this tool versus alternatives (e.g., other list tools) is provided. The description lacks context for selection.

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 must disclose behavioral traits, but it only states the output content. It does not mention that the operation is read-only, authentication needs, rate limits, or any side effects. The token parameter is listed in the schema but not explained in the 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 single concise sentence of about 20 words, with no wasted words. It front-loads the key information, though it lacks structural elements like bullet points or examples.

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 simplicity (1 param, no output schema, no annotations), the description is insufficient. It does not explain the token requirement, the return format, or how to interpret verdicts. With 19 sibling tools, more context would aid selection.

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

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

Schema description coverage is 0%, and the description provides no explanation of the 'token' parameter's role or format. The description adds no value beyond the minimal schema definition.

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 specifies that the tool lists tracked buyer questions that are re-asked weekly, with each engine's verdict. The title 'List tracked buyer questions' and description together clearly identify the resource and action, distinguishing it from siblings like 'track_prompt' which creates prompts.

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

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

No guidance is provided on when to use this tool versus alternatives such as 'track_prompt' or 'ai_traffic'. The description only states what the tool does, without any context for decision-making or 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 carries full burden for behavioral disclosure. It only states 'list pending' without explaining side effects, authentication requirements, rate limits, or whether it mutates data (though implied read-only, not confirmed). Minimal transparency.

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 concise sentence with no waste. However, it sacrifices critical details for brevity, which slightly lowers the 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 no output schema, no annotations, and a single under-documented parameter, the description is insufficient. It lacks details on output format, pagination, error conditions, or interpretation of 'pending'.

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 only parameter 'token' has no description in the schema (0% coverage) and the tool description does not explain its purpose or format. The agent is left to guess it is an authentication token, which is insufficient.

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 pending Reddit opportunities, including copy-paste drafts and thread links, tailored to the user's account. This is specific and distinguishes it from siblings like 'find_reddit_opportunities' (likely search) and 'mark_reddit_opportunity' (likely update).

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

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

No guidance is provided on when to use this tool versus alternatives. The description only states what it does, with no conditions, exclusions, or hints about prerequisites like having a connected Reddit account.

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 burden. It reveals that the tool updates status to remove from queue, but does not detail side effects (e.g., irreversible action, required permissions) or any additional constraints. Adequate but not thorough.

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 that conveys the essential context. It is concise without unnecessary words, though it could be slightly more structured to separate when and how.

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 3 parameters, no output schema, and no annotations, the description is too brief. It does not explain the optional 'published_url' parameter, nor what happens after marking (e.g., confirmation, error cases). Essential details are missing for a tool operating on a queue.

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

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

Schema description coverage is 0% and the description adds no information about the parameters (id, status, published_url). The description fails to clarify what 'published_url' represents or how 'status' affects behavior, leaving the agent entirely dependent on 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 specifies the verb 'mark' and the resource (draft content) and indicates the outcome ('leaves the queue'). It clearly distinguishes this tool from siblings like 'write_article' or 'list_content_queue' by focusing on post-publish/dismissal marking.

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 contextual guidance ('After you publish a draft yourself or decide to skip it'), implying when to use it. However, it does not mention when not to use it or list alternatives such as 'list_content_queue' for reviewing drafts.

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 provided, so description carries the burden. It explains the effect (removes from queue) but lacks details on side effects, reversibility, or permissions. Adequate for a simple status update.

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?

Single, well-structured sentence that front-loads the purpose and usage. No unnecessary 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 the tool's simplicity (2 params with enum, no output schema), the description covers the core behavior and usage. However, parameter semantics could be richer. Still sufficiently complete for an agent.

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 50% (only id described). Description adds no parameter-level detail beyond what the schema provides. The status enum is not explained.

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 marks a Reddit opportunity as posted or dismissed, with explicit context about removing it from the queue. It distinguishes itself from sibling tools like list_reddit_queue and find_reddit_opportunities.

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 specific usage guidance: after posting a drafted reply or deciding to skip it. It implicitly tells when to use, but does not explicitly mention when not to use or contrast with 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 provided, the description carries full burden. It fails to disclose the safety profile (e.g., read-only vs destructive), authorization requirements, error handling, or any side effects. The phrase 'using your account token' hints at authentication but lacks detail.

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

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

The description is a single concise sentence that front-loads the key purpose. No extraneous words 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 the simple parameter set and no output schema or annotations, the description should cover prerequisites (subscription), return format, and error scenarios. It only mentions token usage and report contents, leaving significant gaps.

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

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

The description adds minimal context for the single 'token' parameter by stating it's an account token. However, with 0% schema description coverage, it should provide more detail (e.g., token format, source, requirement status). The description does not fully compensate for the missing schema documentation.

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

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

Description clearly states it retrieves the latest weekly report for a subscribed client with specific contents (verbatim answers, quick wins). However, it does not explicitly differentiate from sibling tools like get_audit or visibility_history.

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

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

The description implies the tool requires a subscription and an account token, but it provides no explicit guidance on when to use this tool versus other siblings, nor any conditions for not using 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?

With no annotations, the description does not disclose behavioral traits beyond being read-only (implied by 'snapshot') and mentions authentication via token. However, it does not explain what happens if the token is invalid or missing, nor does it describe any rate limits or 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?

A single sentence that is front-loaded with the core purpose and includes necessary context. No wasted words.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description is adequate but lacks details on the return format of the 'snapshot+trend'. While sibling tools provide context, the description alone is slightly incomplete for full understanding.

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 covers the parameter with a description, and the description adds context by stating 'using your account token', clarifying its purpose for authentication. This reinforces the schema without adding redundancy.

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 provides the latest AI-visibility snapshot and trend for subscribed Incisory clients, using a verb 'get' implied by 'latest'. It distinguishes from siblings like 'visibility_history' by focusing on the latest snapshot and trend rather than historical data.

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

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

No explicit guidance on when to use this tool versus alternatives. The only clue is 'for a subscribed Incisory client', but no mention of when not to use it or which sibling tool to use for other cases.

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 must convey all behavioral traits. It only describes the three modes without disclosing side effects, persistence, or what happens after setting autonomy.

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 concise sentence that front-loads the action. It is clear and to the point, though it could benefit from a bit more structure.

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

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

Given no output schema and no annotations, the description lacks completeness. It does not explain return values, confirmation, or any side effects, leaving the agent uncertain about the tool's full behavior.

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

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

Schema coverage is 0% but the description adds meaning to the 'autonomy' parameter by explaining each enum value. The 'token' parameter is not explained, but the main parameter is covered 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 the verb 'choose' and the resource 'autonomy of Incisory', listing the three specific modes. It distinguishes itself from sibling tools which handle different aspects like traffic or visibility.

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

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

The description implies the tool is for setting autonomy level but does not explicitly state when to use or not use it, nor does it mention alternatives. The context is clear but lacks explicit 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?

No annotations are provided, so the description fully carries the burden. It discloses key behaviors: the question is re-asked across ChatGPT/Gemini/Perplexity every weekly scan, and there is a maximum of 12 tracked questions. This is sufficient for understanding the tool's 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?

The description is concise, with two sentences that clearly state purpose, behavior, and a limit. It is front-loaded with the main action. Slightly more structure could improve readability.

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 and two parameters, the description covers essential aspects: what it does, how it works (weekly scan across platforms), and constraints (max 12). However, it lacks details on error handling, token usage, and what happens when the limit is reached. There are gaps that a more complete description would fill.

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

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

Schema coverage is 50% (only 'text' described). The description adds meaning for 'text' by giving an example and explaining its purpose. However, the 'token' parameter has no description, and the description does not compensate for the missing documentation.

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

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

The description clearly states the action ('Add') and the resource ('a question your buyers ask'), and distinguishes from sibling tools by mentioning tracking across multiple AI platforms for trend analysis.

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

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

The description explains when to use the tool (to track a buyer question for per-question trends) and sets a context (re-asked weekly), but does not explicitly state when not to use it or name alternative 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 full behavioral burden. It states it gets a Stripe checkout link but does not disclose side effects (e.g., if a subscription is created immediately), authentication requirements, or behavior if already subscribed. The mutation aspect is implied but not explicit.

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?

Single sentence with no filler. Front-loaded with the action and resource, then concise details. Every word 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?

Given zero parameters, no output schema, and the simple action of getting a checkout link, the description is complete. It covers what tool does, available plans, and trial. No additional context needed.

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

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

There are zero parameters, so baseline is 4. The description adds value by specifying the plans and trial, compensating for lack of user input needed. Schema coverage is 100% inherently.

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 'Get the Stripe checkout link' and resource 'subscribe', distinguishing it from sibling tools like write_article or google_data. It provides specific plan details (€29/mo Track, €79/mo Engine) and mentions the free trial.

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 tells the agent to use this tool 'to subscribe' and lists available plans with trial, giving clear context for when to invoke. It lacks explicit exclusions or alternatives, but no sibling tools overlap in billing domain.

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 only mentions 'visibility trend across weekly snapshots' but does not disclose whether it is read-only, whether it requires specific permissions, or what side effects (if any) exist. The behavior is vaguely implied but not transparent.

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, concise sentence that front-loads the key purpose. However, it may be too brief given the lack of other documentation; it earns its place but could benefit from slight expansion.

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 lack of output schema and annotations, the description is insufficiently complete. It does not explain what the output contains, how weekly snapshots are structured, or any limitations. A tool with one parameter should provide more context to be fully usable.

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 0% description coverage for the single parameter 'slug'. The description adds minimal context ('registered client slug') but does not explain format, validation rules, or how to obtain a valid slug.

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 (trend) and resource (visibility for a client slug), but it does not differentiate from sibling tools like audit_visibility or my_visibility, though the 'weekly snapshots' aspect adds some specificity.

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

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

No guidance is provided on when to use this tool versus alternatives. The description lacks any context about prerequisites, when not to use it, or what distinguishes it from similar 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses that the article is not auto-published, is stored as a draft, and includes title, body, and FAQ schema. This is sufficient for a write tool.

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

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

Two sentences that are front-loaded with the core purpose and include essential details like storage and authentication. Every word 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?

Given 5 parameters, no output schema, and no nested objects, the description sufficiently explains the output (draft with title, body, FAQ schema) and workflow (stored in content queue). No major gaps.

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

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

Schema coverage is only 20% (only target_prompt described). The description adds meaning: target_prompt is the buyer question, and business/website/niche are for ad-hoc drafts. This compensates for the low 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 clearly states the tool's purpose: generating a branded article designed for AI citation, targeting a specific buyer question. The verb 'Generate' and resource 'article' are specific, and the purpose is distinct from siblings like 'citation_gap' or 'ai_traffic'.

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

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

The description explains that the article is a draft stored in the content queue for review, not auto-published. It also provides options for authentication (token vs. ad-hoc parameters). While it doesn't explicitly say when not to use it, the context of siblings implies its unique role.

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