Miraqo

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

With no annotations provided, the description carries the full burden and does a solid job: it discloses credit consumption tied to sources and the credit_weights field, explicitly labels the action as paid, and mentions the monthly quota and dedicated MCP cap. It does not mention return values or failure behavior, but the material side effects are well covered.

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

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

The description is three purposeful sentences: main action first, then cost behavior, then a reference to get_usage. There is no filler or redundancy, and the most important operational constraint (the paid nature) is prominent.

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 6 parameters, no annotations, and no output schema, the description covers the core behavior and cost implications but leaves gaps: it does not describe what the tool returns (e.g., an ID or status), how failures or insufficient credits are handled, or how to choose between this and run_ai_visibility_check. It is adequate but not exhaustive.

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%, so the description must compensate. It adds real meaning to the 'sources' parameter by linking it to credit_weights from get_ai_visibility. However, it does not clarify project_id, query, or intent_category semantics, leaving the enums and schema to carry most of the load.

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 ('Crea un prompt di Presenza AI') and the resource (an AI Presence prompt), and adds that it 'avvia il primo check' (starts the first check). It does not, however, explicitly distinguish itself from the sibling run_ai_visibility_check, so it stops short of full sibling differentiation.

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 its use case: you call this to create a new prompt and trigger the initial check. It adds cost context by warning it is a paid action and by pointing to get_usage for remaining credits, but it never states when not to use it or names alternatives for re-running checks.

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 that the tool returns diagnostic fields and enforces a maximum of 30 results, which is useful. However, it does not mention potential side effects (though likely read-only), error conditions, authentication needs, or any other behavioral constraints.

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

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

The description is extremely concise, consisting of two short sentences. The core purpose is front-loaded, and the result limit is clearly stated. There is no redundant language; every phrase 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?

The tool has no annotations, no output schema, and minimal schema descriptions. The description provides the search function and return fields, but omits parameter details for 'view' and 'project_id', and gives no usage context relative to siblings. An agent may not know how to set these parameters 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 descriptions coverage is 0%, so the description must compensate. It explains that 'query' is a substring for URL or title, but does not explain the 'view' parameter (enum auto/structural/ai) or the 'project_id' parameter. The list of diagnostic fields is not parameter-specific and does not clarify 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 states a specific verb (search) and resource (pages), and further specifies the search mechanism (substring in URL or title) and the returned content (diagnostic fields). This effectively distinguishes it from sibling tools like get_cluster_pages or get_audit_pages, which have different intents.

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

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

There is no explicit guidance on when to use this tool versus alternatives. The description does not mention conditions like 'use when you need to find pages by text' or name a more suitable sibling. The context implies search use, but it is not directly stated.

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

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses cache behavior (returns free if already generated), cost (1 AI bridge, plus a paid action consuming plan quota and MCP action), monthly caps, and a pointer to get_usage. This goes well beyond a minimal mutation warning.

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 every sentence carries operational detail. However, the cost information is split across two sentences with some redundancy ('consuma 1 ponte AI' and 'AZIONE A PAGAMENTO: consuma 1 unità... e 1 azione MCP'), making it slightly denser than necessary.

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

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

For a 3-parameter tool with no output schema and no annotations, the description covers output form, parameter domain, caching, and billing comprehensively. It leaves project_id's role implicit and does not specify exactly what 'anchor' means, but the essential invocation context is well covered.

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 describes source and target as URLs. The description adds that source/target may also be node-ids, that they refer to pages from the last audit, and that the intended relationship is pillar→orphan. project_id is not elaborated, and with 67% schema coverage the description partially compensates but leaves one parameter reliant on schema-only 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 opens with a concrete verb ('Genera') and a specific resource ('ponte semantico' paragraph with anchor), then defines the exact use case: linking a target page from a source page, explicitly identified as the pillar→orphan pair of the Action Plan. This clearly distinguishes it from the many getter and analysis 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?

It provides clear context for when the tool applies (pillar→orphan pairs from the last audit) and directs the agent to get_usage for remaining credits. It does not explicitly name alternative tools or state when not to use it, though the cache-free note implies a decision point.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explains what data is returned in each mode (mentions, citations, Share of Voice, credit weight, history). It does not mention freshness, pagination, rate limits, or side effects, but for a read-only getter this is partially acceptable.

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

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

Two concise sentences are front-loaded with the core purpose and then structured by parameter mode. Every sentence adds meaningful information, and there is no redundant or filler 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 there is no output schema FM, the description must explain return values, and it does so at a high level. However, it stops short of describing the response structure, how results are ordered, or how project_id and prompt_id are resolved. Enough for basic use, but an agent would still be uncertain about exact output shape.

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 50%: prompt_id has no schema description FK. The description compensates well by explaining the semantic difference between omitting prompt_id and providing it, and by listing the returned metrics. It does not specify prompt_id origin, but that is a minor 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 tool retrieves AI presence data for a project and distinguishes two modes based on prompt_id: aggregated latest results per source, or historical results for a specific prompt. This is specific and actionable, though it does not explicitly differentiate from sibling tool run_ai_visibility_check.

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

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

The description implies when to use it with or without prompt_id by explaining the two behavior modes. However, it gives no explicit guidance about when to choose this tool over alternatives like run_ai_visibility_check, nor does it state exclusions or prerequisites.

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 for behavioral disclosure. It states the tool is a 'get' (implying read-only) but does not mention any side effects, data freshness, pagination, or whether the audit must have been run via run_audit first. The verb implies safety, but no explicit behavioral details are added.

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, well-structured sentence in Italian that front-loads the key output types and lists example issues. There is no redundancy or filler; it earns its place.

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

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

For a single-parameter tool with no output schema, the description covers the return contents adequately (score, scanned pages, issue counters) and clarifies it is for the last completed audit. It could mention whether the audit must exist or how to trigger one, but that is a minor gap given the 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 input schema already describes project_id with a note to use list_projects, and schema coverage is 100%. The description adds no additional semantic detail about the parameter beyond what the schema provides, so the baseline of 3 applies.

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

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

The description clearly states the tool returns issues from the last completed SEO audit, specifying the content (score, scanned pages, non-zero issue counters) and lists example issue types. This distinguishes it from siblings like get_audit_overview (likely a summary) and get_audit_pages (page-level details).

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 given on when to use this tool versus the sibling tools such as get_audit_overview, get_audit_pages, or get_audit_redirects. The description does not mention any preconditions, ordering, or alternatives, leaving the agent to infer usage from context.

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

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

There are no annotations, so the description carries the burden of explaining behavior. It does disclose that the tool returns a summary with score, pages, errors, and topical architecture availability, and it scopes results to the last completed audit. However, it does not state whether the operation is read-only, what happens when no audit exists, or whether the data is cached.

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

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

The description is a single compact sentence that front-loads the core purpose and uses a colon to list the response contents. There is no redundant or filler wording.

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

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

With no output schema, the description reasonably explains what the return value contains. For a simple one-parameter getter this is mostly sufficient, though it omits edge-case behavior such as a missing audit or how detailed the pages/errors sections are.

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 project_id is fully documented in the schema with a clear description and source hint ('da list_projects'). The tool description adds no parameter-level information, but 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 clearly defines the tool as a summary of the last completed SEO audit for a project and enumerates the included content: score, pages, errors, and topical architecture availability. This distinguishes it from sibling tools like get_audit_pages, get_audit_issues, and get_topical_architecture, which provide specific details rather than an overview.

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 given about when to use this tool instead of the related audit tools, nor does it state prerequisites such as running an audit first. The phrase 'ultimo SEO audit completato' only implies that an audit must already exist, but this is not made explicit.

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

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

With no annotations provided, the description carries the full burden. It discloses pagination (max 100), the crawler's behavior of following redirects and saving the final status (thus excluding redirects from results), and implies sorting/filtering capabilities. It doesn't cover error handling or return format, but the key behavioral traits are well communicated.

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

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

The description is two sentences, front-loaded with the core purpose, followed by filtering/sorting/pagination details and the redirect caveat. Every sentence earns its place with no redundancy or fluff, making it highly efficient.

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

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

For a paginated list tool with no output schema and no annotations, the description covers the primary use, parameter behavior, an edge case, and an alternative tool. It lists the returned fields in the first sentence and mentions pagination limits. It doesn't detail error handling or authentication, but these are likely platform-level concerns. It is fairly complete for its complexity.

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% (project_id alone has a description). The description explains the issue parameter's special value ('errors' = 4xx/5xx) and mentions filtering and sorting, plus pagination limits. However, it doesn't elaborate on other enum values for issue or order_by, leaving the agent to infer their meaning. Given the low schema coverage, it should compensate more, but it does add some value.

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

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

The description clearly states the tool returns pages from the latest SEO audit with specific fields (status, title, word count, load/LCP/TTI times, issue flags). It also distinguishes itself from get_audit_redirects by explicitly noting that redirects are not included, making its scope precise and easily differentiable from 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 instructs when to use get_audit_redirects instead (for redirects), and clarifies the special meaning of issue='errors' as 4xx/5xx pages. It provides clear context for when this tool is appropriate, even though it doesn't mention every sibling, the named alternative and condition satisfy the 'explicit when-not/alternatives' criterion.

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 describes the output structure (redirect chains with fields and linked_from pages) and clarifies it applies to the last audit, but it doesn't state whether the operation is read-only, mention any side effects, or note any limitations such as pagination behavior. As a 'get' tool, it's likely safe, but this is not explicitly stated.

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

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

The description is concise, consisting of two sentences with the main content front-loaded. It includes useful context about the linked_from field and its relationship to get_audit_issues without any fluff. It's well-structured and easy to parse.

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

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

The description explains what the tool returns and its purpose, but it lacks parameter guidance and doesn't mention pagination behavior. For a paginated list tool with no output schema, it is partially complete but misses some useful context an agent would need to call it correctly (e.g., what limit/offset control, or that results are from the most recent audit).

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% (only project_id has a description). The description adds no parameter semantics; it doesn't explain the purpose or format of limit or offset beyond their schema constraints (min/max). With low coverage, the description should compensate but fails to do so.

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 function: returning redirect chains from the last audit, listing specific fields (initial URL, hop, final destination, status, loop) and the linked_from pages. It also ties it to the errors_redirect counter of get_audit_issues, making its purpose and relationship to siblings unambiguous.

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

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

The description implies it is used for detailed redirect chain data behind the errors_redirect counter, but it doesn't explicitly state when to use it instead of related tools like get_audit_issues or get_audit_pages. It provides context but no explicit when-to-use or when-not-to-use guidance, nor mentions any alternatives.

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

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

With no annotations, the description carries the full burden. It discloses that data comes from the last snapshot, is paginated (max 100), and describes the returned fields. However, it does not explicitly state that the operation is read-only or non-destructive, nor does it mention authentication or potential side effects. It provides decent behavioral context but leaves the safety profile implicit.

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

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

The description is a single, well-structured sentence that front-loads the core purpose and lists key output fields. It contains no filler and delivers maximum information in minimal space.

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 read-only getter with no output schema, the description adequately covers the return contents (totals and row fields) and pagination. It mentions the snapshot context and max limit. It does not address error conditions or prerequisites beyond project_id, but those are minor for this type of 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 coverage is only 20% (only project_id has a description). The description adds meaning for the limit parameter by stating 'Paginato (max 100)', but it does not explain offset, status, or order_by beyond what the enums self-describe. Given the low coverage, the description should compensate more thoroughly, but it only partially does.

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 retrieves monitored backlinks for a project, including snapshot totals (new/lost, referring domains, domain rank) and detailed rows with anchor, dofollow, status, and spam score. This specific verb+resource distinguishes it from all sibling tools, none of which handle backlinks.

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 used to fetch backlink data for a project but does not explicitly state when to use it versus alternatives or any prerequisites. Since no sibling covers backlinks, the guidance is adequate but not explicit; it lacks any mention of exclusions or 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?

With no annotations provided, the description carries the full burden and does disclose useful behavioral details: ordering by in-link, included diagnostic fields, and pagination up to 100. However, it does not mention defaults for limit/offset, sort direction, or how the 'view' parameter affects results.

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 compact and front-loaded, conveying purpose, scope, ordering, fields, and pagination in two sentences. The field list is somewhat long but valuable for an agent; there is no filler or redundant phrasing.

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 five parameters, no output schema, and no annotations, the description is incomplete. It communicates the core output and sorting, but omits essential guidance on the 'view' enum, pagination defaults, and required project context, leaving an agent to infer or guess.

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 20%, so the description should compensate for the undocumented parameters. It explains the cluster scope and pagination, but leaves 'view', 'project_id', 'limit', and 'offset' unexplained 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 clearly identifies the resource and action: it returns pages of a cluster/silo or the whole site, ordered by in-link, with specific diagnostic fields. It is specific enough to distinguish from broad page-list tools like find_pages, though it lacks an explicit verb such as 'retrieves' or 'lists'.

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

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

Usage is implied: the tool is for retrieving pages within a cluster/silo or sitewide, with diagnostic fields. It clarifies that omitting the cluster yields sitewide results, but it does not explicitly discuss when to choose this tool over alternatives like get_topical_architecture or find_pages.

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 returned data types but does not state whether the operation is read-only (though implied by 'get'), any rate limits, permission requirements, or behavior on invalid input. This is minimal for a tool with no annotation support.

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, well-structured sentence in Italian that conveys the core purpose and return content without fluff. It is appropriately front-loaded and concise.

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 getter with no output schema, the description provides the essential output description (average position and keyword gap counts). However, it lacks detail on the result format (e.g., nested structure, units) and any usage context, leaving the agent with only partial information for interpreting results.

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% since the only parameter project_id is described as 'ID progetto (da list_projects)'. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the resource (competitors of a project) and what it returns (average keyword position and keyword gap counts). It is specific enough to distinguish from generic getters, though it doesn't explicitly name alternatives like get_keyword_gap.

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 sibling tools like get_keyword_gap. It does not mention prerequisites beyond project_id (which is in the schema) or any context that would help an agent choose 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It conveys a read-only report operation by listing returned content, but it does not explicitly mention side effects, authentication needs, caching, or data freshness, although the tool appears side-effect-free.

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 well-structured sentence that front-loads the main purpose and then lists the report's components. Every element adds useful selection information and there is 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?

For a one-parameter report tool with no output schema, the description does a good job enumerating what the report contains. It does not specify output structure or units, but the simple interface and explicit content list make it sufficiently complete.

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

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

Schema coverage is 100% for project_id, and the schema already describes it as the project ID from list_projects. The description adds no additional parameter-specific meaning, 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 clearly identifies the tool as delivering a Core Web Vitals report for the last audit and enumerates specific contents: PSI-sampled pages, metrics, CrUX field data, AI development tickets, and the 10 worst LCP pages. It is clearly distinct from sibling audit tools by topic, though it does not explicitly contrast itself with any sibling.

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

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

The phrase 'dell'ultimo audit' implies this tool targets the most recent audit, which gives some contextual guidance. However, it does not explain when to prefer this tool over get_audit_* siblings or when it should not be used.

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 clearly discloses that this is a read-only cache operation (no side effects), and describes the fallback behavior when location_code is omitted, plus notes that market fields are always present. This is substantial behavioral context beyond a simple read hint.

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-loaded with the tool's purpose and content list, followed by usage guidance. No filler or repetition. 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?

The description lists the key components of the snapshot (authority, backlinks, organic keywords, top keywords, pages), which is essential since there is no output schema. It also explains market behavior. It doesn't mention error cases or pagination, but for a read-only snapshot this is adequate.

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 75% (3 of 4 params have descriptions). The description adds semantics for location_code by explaining the effect of omitting it, which the schema alone doesn't convey. It doesn't add detail for organization_id, but the schema already lacks a description there, so the description partially compensates for the gap.

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

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

The description states a specific verb ('Snapshot') and resource ('analisi della concorrenza di un dominio'), and enumerates the exact content (authority, backlinks, organic keywords, top keywords, pages). It also distinguishes itself from the sibling run_domain_analysis by explicitly saying this is a cache read-only snapshot, so an agent can tell them apart without opening schemas.

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 when to use this tool ('Solo lettura della cache') and when to use the alternative ('per aggiornare usa run_domain_analysis'). It also clarifies the behavior without location_code (returns most recent analysis across markets), which guides selection when market-specific data isn't needed.

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 explicitly states the operation is read-only and consumes zero credits, explains that include_responses=true adds long raw AI responses, and discloses that a null audit means no completed audit exists. This is solid coverage of non-obvious behavior, though it omits authentication or error details.

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 front-loads the main purpose and then adds the most relevant operational notes about credits, parameter behavior, and null results. It is a single dense block rather than cleanly separated sentences, but every clause adds useful information and nothing is wasted.

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 retrieval with two parameters and no output schema, the description conveys the returned content, the meaning of a null result, and the effect of the optional parameter. It does not describe the response format in detail, but the content list and null-handling note give an agent enough to understand 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 description coverage is only 50%, with include_responses lacking a schema description. The description compensates by explaining that setting include_responses=true adds raw AI responses and that they can be long. project_id is already documented in the schema as coming from list_projects, so the main semantic gap is addressed.

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 purpose: retrieving the latest completed GEO Audit for a project, including how ChatGPT, Gemini, and Perplexity describe the brand. The parenthetical content list adds specificity. It does not explicitly distinguish itself from sibling audit tools like get_audit_overview or get_ai_visibility, 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?

The description provides useful usage context: the tool is read-only, costs zero credits, and the audit itself is launched from the app. It also explains the meaning of a null audit. However, it does not explicitly state when to prefer this tool over alternatives such as get_ai_visibility or get_audit_overview, so usage guidance is implied rather than explicit.

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

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

With no annotations provided, the description carries the full burden. It discloses the 'last_synced' field and interprets zero tails as a stuck sync rather than a collapse, which is valuable behavioral context. It also states the 90-day limit and that it's site totals, not per-page. While it doesn't discuss return format or rate limits, it offers meaningful insight beyond a basic 'get data' statement.

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

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

The description is a single dense but efficient sentence that front-loads the core purpose, then adds a sibling comparison and a data-interpretation note. It's not bloated, though it could be slightly better structured by separating the last_synced caveat. Still, every phrase 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 read tool with two parameters and no output schema, the description is fairly complete. It specifies the metric series, the date granularity, the 90-day cap, and how to interpret the last_synced field. It lacks a description of the exact response shape, but the series and last_synced mention provide enough context for an agent to call it correctly.

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

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

Schema description coverage is 50%, with project_id documented in the schema. The description adds 'fino a 90 giorni' which hints at the days parameter's purpose but doesn't explicitly state that days controls the number of days or its default value. It partially compensates for the undocumented days parameter but doesn't fully clarify its semantics.

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

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

The description clearly states the tool returns a day-by-day series of site totals from Search Console with specific metrics (clicks, impressions, CTR, average position) and a 90-day limit. It explicitly contrasts with get_gsc_performance, establishing its unique role as the only GSC data with real dates, which distinguishes it from 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 provides explicit when-to-use guidance: 'usalo per datare un calo o un picco' (use it to date a drop or a peak) and explains that get_gsc_performance is for which queries/pages but only aggregated over fixed windows. It also clarifies scope with 'Totali di sito, non per pagina', preventing misuse.

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

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

With no annotations provided, the description carries the full burden and does so well: it reveals pre-aggregation into 7/28/90-day windows, the rounding-up behavior for other values, the effective vs requested window fields (`days` vs `days_requested`), and the absence of daily granularity. No annotation contradiction exists.

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

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

Three dense sentences: purpose/metrics first, then aggregation semantics, then the explicit alternative. Every sentence earns its place and the most decision-relevant contrast 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 4-parameter tool with no annotations and no output schema, the description covers purpose, metrics, dimensions, and the unusual window rounding behavior. The main gap is the lack of any explanation for `limit` and a fuller picture of the response shape, though the named fields and metrics make it mostly adequate.

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 low (25%), so the description meaningfully compensates by explaining the `days` window behavior and the `dimension` options ('per query o pagina'). However, the `limit` parameter and the exact relationship between `days_requested` and the query parameter are not fully elaborated, leaving a small but real semantic gap.

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

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

The description states exactly what the tool does: it returns Search Console performance aggregated by query or page, with period totals for clicks, impressions, CTR, and average position. It also explicitly contrasts itself with get_gsc_daily, so the agent can distinguish it from the closest sibling.

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

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

The description explicitly says this tool provides no day-by-day history and instructs agents to use get_gsc_daily when dating a decline. This is a clear when-to-use/when-not-to-use statement with a named alternative.

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 pagination (max 100), the default of only_uncovered, and the data returned. However, it does not mention whether the operation is read-only, any authentication requirements, or error conditions. The disclosure is adequate but not exhaustive.

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

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

The description is concise and front-loaded, starting with the core purpose and then detailing the key parameter and pagination. Every sentence adds information without unnecessary fluff.

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

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

For a tool with 6 parameters, no output schema, and no annotations, the description covers the essential aspects: the returned fields, the key parameter behavior, and pagination. It does not elaborate on error handling or edge cases, but for a straightforward retrieval tool, it is sufficiently complete.

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

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

Schema description coverage is 50% (3/6 parameters have descriptions). The description adds value for only_uncovered by explaining its default and effect, but it does not clarify limit, offset, or location_code beyond the schema. The provided information is helpful but not fully compensating for the coverage gap.

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

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

The description clearly states the tool retrieves keyword gaps from competitors, listing the returned fields (volume, position, difficulty, CPC, URL). It implies a distinction from get_keywords by specifying 'gap' and 'competitor', though it does not explicitly name a sibling. The purpose is unambiguous and specific.

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

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

The description implies usage for competitor keyword analysis and explains the default behavior of only_uncovered, but it does not explicitly state when to use this tool versus alternatives like get_keywords or get_competitors. No exclusions or alternative routing are 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?

No annotations are provided, so the description carries the burden. It discloses the data scope (position history up to 365 days), the inclusion of SERP features (AI Overview, featured snippet, AIO citations), and the constraint that the keyword must be tracked. However, it does not explicitly state that the operation is read-only, mention any prerequisites beyond tracking, or describe error behaviors (e.g., unfound keyword, untracked keyword). It adds some behavioral context but not 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?

A single sentence that front-loads the core purpose and adds key qualifiers (365 days, SERP features) with no filler. It is compact and easy to parse.

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

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

There is no output schema and no annotations, so the description must explain what an agent can expect. It states the general return shape (position history with SERP features) but does not clarify the structure of the response, the meaning of each SERP feature, or how optional parameters affect the output. For a tool with 4 parameters and no output schema, this is insufficient for confident 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 50%; keyword and project_id are documented in the schema, but days and device have no descriptions. The description mentions 'fino a 365 giorni', which hints at the days parameter, but does not explain how days controls the history length or that device filters by desktop/mobile. It fails to compensate for the two undocumented parameters.

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: 'Storico posizioni di una keyword tracciata' (history of positions of a tracked keyword), with a clear scope (up to 365 days) and a list of SERP features. This distinguishes it from siblings like get_keywords (keyword list), get_keyword_gap (comparison), and get_youtube_rankings (YouTube-specific).

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

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

The description implies the tool is for retrieving a keyword's position history, but it provides no explicit guidance on when to choose it over alternatives, no prerequisites beyond 'tracked keyword', and no exclusions. There is no mention of when to use get_keywords vs get_keyword_history, or what makes this tool the right choice.

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

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: change encoding (positive = rise, negative = drop, outside Top 100 counts as 100), the summary contents, and a 100-row page cap. It omits permissions/auth and rate-limit context, but for a read-style listing tool the return-semantics disclosure is solid.

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

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

Front-loaded with the core action and packed with return-field detail in essentially one dense sentence with zero filler. The breadth of detail makes it slightly heavy, but nothing is wasted or padded.

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 6-parameter tool with no output schema, describing the returned fields and the change/summary encoding usefully substitutes for a missing return spec. However, three parameters (device, limit, offset) remain undocumented anywhere, leaving the definition incomplete 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 coverage is 33% (only project_id and query documented), so the description should compensate. It explains order_by=change but leaves device, limit, and offset semantics unstated, so the coverage gap is only partially filled and the two enums are left to 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?

States a specific verb+resource (tracked keywords of a project) and enumerates the returned fields (last position, previous position, change, URL, AI Overview, summary). This clearly separates it from history/gap siblings implicitly, but it never names an alternative tool, so sibling differentiation is inferred rather than stated.

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 one actionable usage hint (order_by=change surfaces the biggest drops first) and notes pagination, so usage is implied. It offers no when-to-use vs get_keyword_history/get_keyword_gap guidance and no exclusions or prerequisites.

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 disclosure burden. It reveals that the tool operates on the last audit (rather than a user-specified one) and that the 'auto' view defaults to AI when available. However, it does not mention authentication needs, latency, caching, or behavior when no audit exists, leaving important behavioral aspects undocumented.

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

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

The description is a single dense sentence that packs important output details and the view parameter. There is no filler or redundancy. The heavy use of comma-listing without separators and Italian jargon makes it a bit harder to scan, but overall it is concise and information-dense.

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?

It names the main output sections, giving an agent a rough expectation of the return payload. But terms like 'silo_assign', 'anomalie', and the exact meanings of 'structural' and 'ai' view states are not defined, and there is no output schema to fill that gap. Error handling and preconditions are also omitted, so completeness is moderate.

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

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

Schema description coverage is 0%, so the description must add meaning. It explains the 'view' enum values and the default behavior ('auto (default, AI se disponibile)'), but it does not clarify project_id or the difference between 'structural' and 'ai' beyond the AI hint. Thus it compensates only partially for the missing schema documentation.

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

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

The description names a specific resource ('topical architecture of the last audit') and enumerates the contained sections (summary, clusters/silos with pillar URL, in/out links, word counts, silo source, diagnostics). This is more specific than a simple 'get data' and lets an agent understand what the tool returns, though it doesn't explicitly contrast it with siblings like get_cluster_pages or get_audit_overview.

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

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

There is no guidance on when to use this tool versus alternatives. The description only defines the output and view options; it never states scenarios, exclusions, or how it relates to sibling tools such as get_audit_pages or refine_topical_architecture. An agent has to infer the use case.

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 disclosing behavior. It correctly implies this is a read-only operation (a getter), which is safe. However, it does not explain what happens when the optional organization_id is omitted (whether it defaults to the authenticated org, errors, or returns aggregate data). It also does not mention any authentication requirements or rate limiting. The lack of detail on the optional parameter's behavior is a notable gap.

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, which is concise and front-loads the primary purpose (consumption vs plan limits). However, the long list of usage categories runs together without bullets or separators, making it slightly harder to parse quickly. It is efficient but could benefit from light structuring, such as commas or a colon, to improve scannability.

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

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

For a simple one-parameter tool with no output schema, the description covers the return content well by enumerating the metrics. However, it is incomplete regarding the optional parameter: an agent cannot infer whether organization_id is required in practice, what a null value means, or if the response is aggregated or per-org. There is also no mention of the response format (e.g., JSON structure) or any pagination, though that may be acceptable given the absence of an output schema. Overall, it is sufficient for a basic understanding but leaves a key gap around the parameter.

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

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

Schema description coverage is 0%, so the description must compensate for the parameter's meaning. The description does not mention organization_id at all. The schema only lists the parameter as an integer with no description, and it is optional. The tool's core purpose (usage vs limits) suggests the organization_id likely scopes the query, but the description offers no explanation, leaving an agent to guess at the parameter's role and possible values.

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

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

The description clearly states the tool returns monthly usage vs plan limits, enumerating the specific categories (keyword searches, audit credits, AI Presence credits, backlinks, competitor analysis, keyword monitoring, MCP action cap). It uses a specific resource ('usage') and context ('vs plan limits'), which distinguishes it from other get_* tools that focus on data outputs rather than consumption quotas. However, it does not explicitly name an alternative or contrast itself with siblings, 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?

The description implies when to use this tool (to check quota consumption against limits), but it provides no explicit when-to-use, when-not-to-use, or alternative routing. There is no mention of scenarios where a different tool might be more appropriate, nor prerequisites like needing an organization context. The guidance is left to inference from the name and description.

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 transparently explains the behavior of different parameter combinations, including the meaning of a null position value. It also implies read-only behavior through the get_ prefix, but does not explicitly state it or disclose any rate limits or authentication requirements.

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 efficiently convey the purpose, modes, and null handling. It front-loads the main function and uses clear structure, with 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?

The description covers the essential aspects: what it returns (top 20 videos with channel, views, title), the two modes, and the null case. It does not specify the exact response format, but given the tool's simplicity and lack of an output schema, this is sufficient for an agent to call 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 schema describes project_id and keyword, but days lacks a description. The description adds meaning by explaining that keyword is optional and triggers historical mode, and that null position means no channel video in the top 20. This compensates for the partial 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 clearly states it retrieves YouTube channel positions for monitored keywords in YouTube search results, specifying the top 20 videos. It distinguishes between two modes (without keyword for latest check per keyword, with keyword for historical data up to 365 days). This is specific and unique among 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 explains when to use the tool based on the presence of the keyword parameter, offering two clear usage scenarios. However, it does not explicitly mention alternatives or exclusions, but the context is clear that this is for YouTube-specific rankings, distinct from other get_ tools. No explicit 'when not to use' guidance is given.

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 that it lists projects visible to the token (scoping), but does not explicitly state that it is read-only, nor does it mention pagination, rate limits, or behavior when no projects exist. For a simple list, this is a moderate gap.

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

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

The description is two concise sentences in Italian, front-loaded with the core purpose and including the key detail (last audit fields) and a usage hint. No wasted words.

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

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

For a tool with no parameters, no output schema, and no annotations, the description is fairly complete: it states what is returned (projects with last audit details) and provides a usage hint. It could be more explicit about the return format (e.g., array of objects) but the implied structure is clear.

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

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

The tool has zero parameters, so schema coverage is 100% trivially. Baseline for zero parameters is 4. The description adds meaning by explaining what the list contains, which is helpful but not essential since there are no parameters to clarify.

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 ('lists') and resource ('SEO projects visible to the token'), and specifies the content (last audit with id, status, date, score). It clearly distinguishes itself from sibling tools like get_audit_issues or run_audit, which focus on specific actions rather than listing projects.

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 frames itself as the 'starting point' for obtaining project_id used by other tools, giving clear context on when to use it. It does not name alternatives or state when not to use it, but the guidance is sufficient for a simple list 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?

With no annotations provided, the description carries the full disclosure burden and does it exceptionally well. It reveals that this is a paid action consuming 1 AI refinement from the monthly budget plus 1 MCP action with a dedicated cap, that it is limited to once per audit, and how it resets. This level of cost/limit/reset transparency is rare and genuinely useful to an agent.

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 action and every sentence carries operational value. However, the budget consumption is stated redundantly twice ('Consuma 1 rifinitura AI del budget mensile del piano' and 'AZIONE A PAGAMENTO: consuma 1 unità della quota mensile del piano'), and the ALL-CAPS emphasis adds noise. Still compact and well-ordered overall.

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 paid, one-shot, mutation-like action with no output schema and no annotations, the description covers the most critical context: prerequisites (last audit), the once-per-audit cap, reset condition, cost, and a credit-check pointer. What's missing is any statement about what the tool returns or what happens if run without a prior audit, which would round it out.

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

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

There is a single integer parameter, project_id, with 0% schema description coverage, and the description never mentions it. Although project_id is largely self-explanatory and standard across sibling tools, the description does not compensate for the schema's lack of documentation at all. Given the low coverage, a 3 is the right ceiling.

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 ('Rifinisce con l'AI i cluster della Topical Architecture dell'ultimo audit') and anchors it to the in-app button 'Rifinisci con AI'. It clearly distinguishes itself from siblings: get_topical_architecture merely reads the architecture while this mutates/refines it, and run_audit is what re-enables it. The scope ('dell'ultimo audit') is precise.

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 strong usage context: it can only be run once per audit, it reactivates only with a new SEO audit, and it consumes plan quota — with a pointer to get_usage for checking residual credits. It does not explicitly state exclusions (e.g., don't run when no audit exists yet), which would have made this 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 the async nature (runs in background, results after minutes), the paid cost (consumes 1 unit of monthly quota and 1 MCP action), and the per-prompt cap. This is strong transparency for side effects. It doesn't mention failure modes or edge cases, but the core behaviors are well covered.

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

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

The description is concise (four sentences) and front-loaded with the core action. It then adds cost and usage information without redundancy. Every sentence contributes essential information, and the structure is clean.

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 that triggers an async, paid operation, the description covers the key context: what it does, where results land, cost implications, and how to check remaining quota. It doesn't describe the immediate return value or error handling, but since there's no output schema and the results are deferred, this is acceptable. It's nearly complete for the agent's decision-making needs.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that prompt_id is optional and filters to a specific prompt, with the default being all active prompts. However, it does not explain project_id beyond the implicit project context, and doesn't detail value formats or constraints. The description adds meaning for prompt_id but not fully for project_id, leaving a partial 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 tool starts a background AI Presence check for project prompts, optionally filtered by prompt_id. It distinguishes itself from get_ai_visibility (which retrieves results) and uses a specific verb ('Avvia') and resource, making the purpose unambiguous.

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

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

It explicitly mentions that results appear in get_ai_visibility after a few minutes, implying the correct workflow (use this to start, then get_ai_visibility to retrieve). It also instructs to use get_usage to check remaining credits before use, addressing the paid-action context. However, it doesn't explicitly contrast with alternative tools or state 'when not to use', but the guidance is clear enough.

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

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

With no annotations provided, the description carries the full disclosure burden, and it does so thoroughly: it reveals that the call costs one MCP action immediately, consumes audit credits based on crawled pages, runs asynchronously in the background, and takes minutes. It also tells where status and results will surface, which is substantial behavioral context beyond what the schema could convey.

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

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

The description is a single dense paragraph with no filler; the main purpose and paid/asynchronous caveat are front-loaded, and each clause contributes billing, timing, status, or result 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?

For a one-parameter, asynchronous, paid action with no output schema, the description covers the essential operational details: what is started, how long it takes, what it costs, and where to monitor status and retrieve results. Nothing critical an agent needs before invoking it appears to be 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 coverage is 0% and the description does not explain project_id at all, so it fails to compensate for the undocumented parameter. The meaning of project_id is inferable from its name, but the definition adds no value beyond the raw integer type.

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

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

The description opens with a specific action verb ('Avvia') and a clear resource ('nuovo SEO Audit del progetto'), and it adds the internal-crawler/background context. This makes run_audit readily distinguishable from the get_audit_* retrieval siblings and the other run_* analysis 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?

It clearly indicates that this tool starts a new audit and points to list_projects for status and get_audit_overview for results, which orients an agent to the correct follow-up tools. It does not explicitly state when not to use it versus all rival run_* tools, but the start-vs-retrieve 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?

Non essendoci annotations, la descrizione si assume pienamente l'onere informativo: chiarisce che i risultati dipendono dal mercato, che uno snapshot recente (<7 giorni) viene riusato gratuitamente (cached=true), che il refresh richiede ~30-60s e che l'azione consuma 1 unità della quota mensile e 1 azione MCP. Sono comportamenti essenziali non deducibili dallo 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?

La descrizione è densa ma ogni frase aggiunge informazione rilevante: scopo, mercato, caching, tempi, costo e controllo crediti. Non ripete lo schema e l'avviso di azione a pagamento è ben evidenziato.

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?

Senza annotations e senza output schema, la descrizione copre input, comportamento, prestazioni e costo in modo sufficiente. Restano non specificati l'organization_id e la struttura esatta del risultato, ma l'insieme è comunque adeguato per un uso corretto.

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?

Lo schema descrive già domain, language_code e location_code con default; la descrizione aggiunge il concetto di 'mercato' e spiega perché lo stesso dominio dà risultati diversi su google.ch vs google.it. organization_id resta però non documentato né nello schema né nella descrizione, un piccolo 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?

La descrizione dichiara chiaramente che lo strumento analizza la concorrenza di un dominio e ne restituisce keyword organiche, traffico stimato e top keyword/pagine. Il purpose è riconoscibile, ma non c'è una distinzione esplicita rispetto al sibling 'get_domain_analysis', che sembra molto simile nello scopo.

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?

Fornisce contesto utile: dati per mercato, default Italia/it, costo a pagamento e suggerimento 'Usa get_usage per i crediti residui'. Non indica però quando preferire questo tool rispetto a get_domain_analysis, get_competitors o get_keywords, né esclude alternative specifiche.

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?

The description discloses the paid nature of the action (1 quota unit and 1 MCP action), the asynchronous job flow, the side effect of marking keywords as tracked when project_id is provided, and that retrieval with job_id does not consume quota. Since no annotations are present, this carries the full burden and does so thoroughly.

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 well organized: it front-loads the core flow and job_id retrieval, then enumerates modes and the quota warning. It could be slightly more structured with bullets, but every sentence contributes useful 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?

For a 10-parameter tool with no output schema and no annotations, the description covers the main usage, costs, and modes, but it omits the exact response structure, error conditions, and whether mode is required for a new search (since required is empty). This leaves agents to guess some invocation 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?

The description adds meaningful semantics for mode (related/list/domain/gap), job_id retrieval, and project_id tracking. However, it does not clarify the purpose of organization_id or the default behavior when no mode is provided, which are not covered in the schema either.

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 launches a keyword research job and returns a job_id, listing four distinct modes. It does not explicitly differentiate it from siblings like get_keyword_gap or get_keywords, but the asynchronous job-based behavior is evident from the text.

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 call the same tool with job_id to retrieve results and to use get_usage for remaining credits. It does not provide explicit guidance on when to choose this tool over get_keywords or get_keyword_gap for direct data access, leaving the selection partially to inference.

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