Vibeking

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond these: it states that country/language are inherited from the site, that it requires an active subscription, and that it counts toward the plan keyword limit. This informs the agent of side effects and constraints without contradicting annotations.

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 with zero filler. The primary action and core constraints are front-loaded, and the permissions/limit context follows naturally. Every phrase adds meaningful 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 simple two-parameter tool with no output schema, the description covers the essential context: who can use it, required subscription, limit impact, and character restrictions. It does not describe the return value or behavior on duplicates, but given idempotentHint and the tool's simplicity, 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 100%—both parameters have descriptions. The description adds the max-80-character limit (already in schema) and clarifies that country/language come from the site, which relates to parameter interpretation but does not introduce new parameter semantics. It meets the baseline for high schema coverage.

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

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

The description states a clear verb ('Add') and specific resource ('keywords to daily Google rank tracking for a website'), and distinguishes itself from the sibling get_keywords by implying a mutating operation. The additional constraints (max 80 characters, country/language from site) make the purpose unmistakable.

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

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

The description provides prerequisites (owners/admins only, active subscription, counts toward plan limit) but does not explicitly contrast with alternative tools like get_keywords or other mutating tools. There is no 'when to use' versus 'when not to use' guidance, though the purpose is self-evident.

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?

Annotations already declare readOnlyHint, idempotentHint and closed-world, so the safety profile is covered. The description does add genuine behavioral context: 'Found does not mean the model read the page', 'robots (latest scan, information only)', and the weekly run spread, all of which shape how an agent should interpret results. It stops short of stating what happens when a site has no AI data or how large the payload can get.

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 entire description is one run-on sentence with deeply nested parentheticals (runSpread, competitorPages, searchFound, foundNotCited, robots), which makes it hard to scan or parse. The purpose is front-loaded, but the return-field catalog is delivered as an undifferentiated wall of text rather than structured clauses.

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 does attempt to cover the return payload, which is the right instinct, and it explains non-obvious fields like runSpread and the robots training signal. It omits error and empty-data behavior and never states which engines are available beyond the three named examples, leaving gaps for a fairly complex reporting 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 100% and both parameters are documented in the schema, including the 1-26 range and default of 4 weeks, so the schema does the heavy lifting. The description never mentions site_id or weeks and adds no meaning beyond the schema, which is the expected baseline of 3.

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 opening clause 'Show AI answer visibility per engine' gives a specific verb and resource, and no sibling tool covers AI answer visibility, so it is distinguishable. However, after the first clause the description stops describing purpose and becomes an inventory of return fields, which muddies what the tool fundamentally is.

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 statement of when to call this versus get_site_metrics, get_competitors, or get_report, and no prerequisites such as 'AI visibility must be enabled for the site'. The only usage-adjacent note is the qualifier 'where enabled', which hints at feature gating without explaining what to do when it is not enabled.

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?

Annotations already declare readOnlyHint, idempotentHint and closed-world, so safety is covered. The description adds genuinely useful behavioral context beyond them: data freshness ('refreshed monthly via DataForSEO') and a 'latest weekly ad library summary', telling the agent how current the results are. It does not disclose pagination or result-size 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?

It is a single front-loaded sentence with no filler, and given there is no output schema, enumerating return fields is defensible. However, the long comma-separated clause list reads as a run-on and hurts 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?

With no output schema, the description carries the burden of describing returns and does so thoroughly (organic keywords, traffic, paid metrics, ad library fields). For a one-parameter read tool this is nearly complete; only pagination/result limits and any usage context are 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 100% and the single site_id parameter is fully documented in the schema (including the list_sites provenance), so the description does not need to explain it. The description adds nothing about the parameter, so the baseline 3 applies.

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

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

States a specific verb (List) and resource (competitors of a website), and enumerates the data categories returned. It is clearly distinguishable from siblings like get_keywords or get_site_metrics. It stops short of a 5 only because the sentence is dominated by a return-field inventory rather than sharpening the purpose statement.

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 when-to-use, when-not-to-use, or alternative guidance. The agent must infer from the name alone that this is the competitor-analysis call. No prerequisites or relationship to sibling tools (e.g. get_keywords) are 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?

Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, covering the safety profile. The description adds no behavioral details beyond the return fields (status, last sync, error), which is not behavioral transparency per se. It does not contradict annotations and provides minimal extra context, so 3 is appropriate.

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 efficiently states the resource, examples, and return fields. There is no filler or redundant 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 simple read-only tool with one parameter and no output schema, the description covers the action, resource, and return content (status, last sync, error). It does not mention pagination or error handling, but given the low complexity and annotation coverage, 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 description coverage is 100%: site_id is fully described as 'The site id, as returned by list_sites.' The description adds no additional parameter semantics, so it does not enhance the schema. Baseline of 3 is correct.

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

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

The description clearly states the verb 'List' and the resource 'data connections of a website', naming specific connection types (Search Console, Analytics, Ads, ChatGPT Ads) and the returned data (status, last sync, error). It is specific enough to distinguish from siblings like get_site_metrics or get_keywords, though it does not explicitly name an alternative.

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 context is only implied: the tool lists connections for a site, so an agent would use it when needing connection status. The schema description adds the prerequisite that site_id must come from list_sites, but there is no explicit when-to-use or when-not-to-use guidance, nor any mention of 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?

Annotations already declare readOnly, idempotent, and closed-world, so the safety profile is covered. The description adds genuine content beyond that: prices are in EUR excluding VAT, titles and descriptions come in both Dutch and English, and the 'access' structure means groups of types where one type per group suffices. It could still note whether the catalogue is static or cached, but the added semantics are substantial.

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 action and then the return fields, with no filler. The parenthetical gloss on access is dense but earns its place by preventing a misread of the nested 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?

With no output schema, the description must describe the return shape, and it names the field groups (price, bilingual title/description, access). It falls short of explaining how those fields are nested or whether fixes carry identifiers needed by order_fix, which an agent would want before acting.

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

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

The tool takes zero parameters, so parameter semantics carry no burden and the baseline is 4. Nothing in the description conflicts with the empty 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 and resource ("List the fixes Vibeking can carry out") and enumerates the fields returned, so the agent knows it is a catalogue read. It never distinguishes itself from close siblings such as get_fix_plan or get_fix_changes, so an agent must infer which one gives the catalogue versus actual fix state.

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 statement of when to call this versus get_fix_plan, get_fix_changes, or order_fix, and no mention that it is a prerequisite for ordering a fix. Usage is only inferable from the word "List".

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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description is not required to state safety. It does add value by detailing what the change set contains (field, before/after values, status), which goes beyond the structured hints. However, it does not disclose potential pagination or the response structure, leaving some behavioral ambiguity. No contradiction with annotations.

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 concisely states the tool's output without extraneous words. The key information is front-loaded: what is returned and its composition. 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 read-only tool with one well-documented parameter and annotations covering safety, the description is mostly adequate. However, there is no output schema, and the description does not clarify whether the result is a list of changes, how pagination works (if any), or the exact structure of the response. The phrase 'per page' is ambiguous, leaving room for misinterpretation.

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 only parameter (order_id) with a clear description ('The fix order id, as returned by list_tasks'). With 100% schema coverage, the description adds no further parameter detail, so a baseline of 3 applies per the rubric.

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 ('Return'), a clear resource ('change set of a fix order'), and elaborates on the content (per page: field, value before and after, status). This clearly distinguishes it from sibling tools like get_fix_catalog or get_fix_plan, which return different aspects of fix orders.

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 purpose (retrieving a fix order's changes) but provides no explicit guidance on when to use it versus alternatives such as get_fix_plan or get_fix_catalog. It neither states prerequisites nor mentions exclusion criteria, leaving the agent to infer from the tool name and sibling 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds that the plan is stored and includes generation timing, which is useful, but it does not address edge cases such as a missing plan or error behavior.

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

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

One sentence, front-loaded with the action and resource, with no filler 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?

For a one-parameter, read-only retrieval tool, the description covers what is returned (steps and generation time) and the annotations cover safety. No output schema exists, but the description gives enough for an agent to invoke it correctly.

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

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

The single parameter task_id is fully documented in the schema with a clear description ('as returned by list_tasks'). The tool description adds no additional parameter-level detail, so the schema carries the burden.

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

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

The description uses a specific verb ('Return') and names a concrete resource ('stored AI fix plan of a task'), and clarifies the content ('steps and when it was generated'). This distinguishes it from sibling tools like get_fix_catalog or get_fix_changes, which concern different fix-related artifacts.

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 makes the tool's context clear: use it to retrieve an existing fix plan for a task. It does not explicitly name alternatives or state when not to use it, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the read-only nature is covered. The description adds value by specifying exactly what data is returned (current value, previous period, baseline, targets, on-track status), which goes beyond the annotations and helps the agent understand the output without an output schema.

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

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

The description is a single, well-structured sentence that front-loads the action and resource, then lists the key data fields. No unnecessary 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 tool has only one parameter and annotations cover safety, the description provides a comprehensive list of what the response will contain (current value, previous period, baseline, targets, on-track status). This is sufficient for an agent to know what to expect, and no critical details are missing.

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

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

The schema fully describes site_id as 'The site id, as returned by list_sites', so the parameter semantics are already clear. The tool description does not add additional meaning beyond that, so a baseline score of 3 is appropriate given high schema coverage.

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

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

The description clearly states the tool shows goals per metric for a website, listing specific data fields (current value, previous period, baseline, targets, on-track status). This differentiates it from siblings like get_site_metrics or get_report by focusing specifically on goals per metric.

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 goal-related metrics, but does not explicitly mention alternatives or when not to use it. However, the clear resource scope (goals per metric) provides sufficient context to distinguish it from other reporting tools, though it lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description still adds real behavioral detail the annotations cannot: the fixed 28-day lookback and the confirmation rule (drops require two consecutive measurements within 3 days, rises count immediately). It says nothing about result ordering or whether results are capped beyond limit.

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 run-on sentence strings together dozens of comma-separated field names with no grouping or bullets, making it hard to scan. The leading clause is well front-loaded, but the remainder reads as an undifferentiated data dump where related concepts (ads, shopping, mobile, opportunities) are not separated.

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?

No output schema exists, so enumerating return fields is legitimately necessary work, and the description covers ranking states, ad data, shopping, bid range, mobile position, intent, competition and opportunities. It is close to complete for a two-parameter read tool, with only ordering and pagination behavior unaddressed.

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

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

Schema coverage is 100% and both parameters are documented in the schema, including the limit default of 50 and the site_id provenance. The description adds no input-side meaning (neither site_id nor limit is mentioned), so the baseline 3 applies; its detail is entirely about returned fields.

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?

Opens with a specific verb and resource: 'List Search Console queries for a website over the last 28 days', then enumerates the tracked-keyword metrics returned. The read/list framing implicitly separates it from add_keywords, but no sibling is named explicitly, so differentiation relies on inference.

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 statement of when to call this versus get_pages, get_competitors, or get_site_metrics, and no prerequisites or exclusions. The only usage constraint conveyed is the fixed 28-day window, which is a scope fact rather than routing guidance.

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

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

Annotations already declare readOnly/idempotent/closed-world, and the description adds real operational context: the 90-day clicks window, that page fields come from the latest completed crawl, and the important caveat that each finding stores only up to 50 example URLs so a page can be affected without being listed. That caveat is exactly the kind of behavior an agent cannot infer from annotations.

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 very long run-on sentence with nested clauses; the core purpose is front-loaded, but the enumeration of status code, title, H1, meta description, findings and sitemap blocks makes it hard to scan. Little is wasted, but structure could be improved with a returned-data breakdown.

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

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

With no output schema and no annotations covering return shape, the description does the heavy lifting by naming the page fields, the findings relationship and the sitemap block. It is close to complete for a read-only listing tool, missing only pagination/default-limit behavior and a pointer to alternatives.

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

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

Schema coverage is 100%, so the schema already documents sort, limit and site_id fully. The description adds only the 'Google clicks over 90 days' framing that implicitly explains the default clicks sort, but nothing about limit or the issues sort beyond what the schema states.

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?

Opens with a specific verb+resource ('List the pages of a website') and enumerates the returned fields, so an agent knows exactly what the tool produces. It never names a sibling (e.g. list_issues) as the alternative for findings-only queries, which keeps it 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?

There is no explicit when-to-use / when-not guidance and no mention of alternatives such as list_issues for finding-level data or get_site_metrics for aggregate metrics. Usage must be inferred from the field list alone.

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?

Annotations already declare readOnly, idempotent, closed-world, so the safety profile is covered. The description adds real context beyond that: demo sites are excluded from results and rows are pre-sorted by attention priority, which affects how the agent should interpret the first entry.

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

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

Two sentences, with the imperative 'Start here' front-loaded and the follow-up routed last. The long field list is dense but every item tells the agent what it will receive, so no sentence 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?

There is no output schema, and the description compensates by enumerating the returned fields and the ordering, plus the scope exclusion. For a zero-parameter read tool with annotations covering safety, an agent has everything needed to call it and interpret the result.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. It correctly implies a no-argument call scoped implicitly to the signed-in user's organizations.

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 resource ('all websites of the signed-in user's organizations') and enumerates exactly what each row carries (site id, status, health score, open critical tasks, open root causes, AI share, last scan). The exclusion of demo sites and the sort order ('what needs attention first') further sharpen the identity, so an agent knows this is the portfolio overview rather than a plain site list.

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?

'Start here' gives an explicit entry-point instruction, and 'Then call get_site_brief for a site' names the natural follow-up tool. What's missing is differentiation from the sibling list_sites, which an agent could plausibly confuse with this tool; no explicit when-not 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?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that the report is 'stored', indicating a pre-existing snapshot rather than live computed data, and it discloses the content categories. No behavioral contradictions are present.

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 action and object, then lists report sections without filler or redundancy.

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

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

For a simple read-only tool with two well-documented parameters, safety annotations, and no output schema, the description covers the core purpose and return contents. It leaves minor ambiguity about the exact response shape and the meaning of 'the three decisions', but this is a small gap for an otherwise simple retrieval tool.

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

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

The input schema fully documents both parameters: site_id is a UUID from list_sites and month uses the yyyy-mm pattern. The description mentions 'website and month' but adds no format, derivation, or usage detail beyond the schema. With 100% schema coverage, the baseline of 3 applies.

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

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

The description states a specific verb ('Return') and resource ('stored monthly report content'), and enumerates the report sections: key numbers, health, AI visibility, fixes, goals, and the three decisions. This clearly separates it from sibling tools that return individual metrics, though it does not explicitly name an alternative.

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 'stored monthly report content' implies this tool retrieves a pre-generated aggregate report, and listing its sections hints that it is an umbrella alternative to several metric-specific siblings. However, there is no explicit when-to-use, when-not-to-use, or alternative tool 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?

Annotations already declare readOnlyHint, idempotentHint and a closed world, so safety is covered. The description adds genuinely new context: this is an aggregate/rollup that bundles a fixed set of signals plus weekly deltas and portal links, implying a single call replaces many. It does not mention latency or payload size for such a broad aggregate.

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 routing instruction and the payload enumeration is dense rather than padded. The middle is one very long comma-chained sentence that is harder to scan than a short bulleted list would be, which costs a point.

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, so the description carries the return-value burden — and it does so by enumerating every section of the brief including derived values (health score with weekly change, top 3 decisions with fix price and orderability). An agent knows exactly what it will get and can decide not to call the detail 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 100% and the single site_id parameter is documented with its provenance ('as returned by get_portfolio or list_sites'), which is stronger than the description provides. The description adds nothing about the parameter, so baseline 3 applies.

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

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

Opens with a specific imperative and scope ('Start here for one website') and then enumerates the exact contents of the answer — plan/scan state, reachability, SSL expiry, health score, AI share, root causes, top decisions, AI visibility, recent changes, portal links. This is unmistakably distinct from siblings like get_site_metrics or get_ai_visibility, which cover single slices.

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?

Gives explicit routing: this is the entry point per site, and 'use the detail tools only for more depth' tells the agent when to escalate. It stops short of naming which sibling covers which depth (e.g. get_ai_visibility for engine-level detail), so the agent still has to map depth requests to specific 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?

Annotations already cover the safety profile (readOnly, idempotent, non-open-world), and the description goes well beyond them with operational semantics: the ssl_days_left metric is explained plus its caveat that it 'does not show which certificate the server serves', and the page_error status is defined as the home page answering with an HTTP error so no score was stored. These are non-obvious behavioral details that materially change how results are interpreted.

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 core purpose is front-loaded in the first clause, and because there is no output schema, the long enumeration of returned sources and fields earns its place. The second half is one run-on sentence with heavy nested clauses, which is dense but not 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?

With no output schema, the description must carry the return-value burden, and it does so thoroughly for every source including pagespeed and crux. Annotations handle safety, so the only real gap is the absence of usage guidance and any note about permission or rate constraints.

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% and both parameters (days, site_id) are documented in the schema, including the default of 30 and the pointer to list_sites. The description's phrasing 'over the last N days' only loosely echoes the days parameter and adds no format or interaction detail beyond the schema, so the baseline 3 applies.

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

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

The description gives a precise verb and resource ('Summarize daily metrics for a website over the last N days') and enumerates exactly which sources and metrics are covered (gsc, ga4, uptime, chatgpt_ads, google_ads, plus pagespeed and crux). That level of detail effectively distinguishes it from siblings, though no sibling is named explicitly, so it falls just 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?

Usage is only implied: 'over the last N days' tells an agent this is the historical daily-metrics summarizer, but there is no when-to-use/when-not-to-use guidance and no pointer to alternatives such as get_pages, get_ai_visibility or get_report. An agent must infer the right context from the enumeration of returned sources.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds context about what data is returned (plan, status, limits, usage, MCP calls this month), which is useful. It doesn't disclose any side effects, rate limits, or auth requirements, but for a read-only tool with annotations, this is acceptable.

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

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

The description is a single sentence that front-loads the key information: what the tool shows and the specific data points. No wasted words, and the MCP calls detail adds value without bloating the text.

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, single-parameter tool with full schema coverage and annotations, the description is nearly complete. It could mention that the organization_id comes from list_sites, but that's already in the schema. The only minor gap is not describing the output format, but there's no output schema and the description lists the data points, which is sufficient.

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

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

Schema description coverage is 100%, so the single parameter organization_id is fully documented in the schema. The description doesn't add extra meaning beyond what the schema provides, but it doesn't need to. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Show') and clearly identifies the resource: an organization's subscription details, including plan, status, limits, and current usage. It also mentions MCP calls this month, which adds specificity and distinguishes it from other get_* 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 implies when to use this tool: when you need subscription/plan/usage information for an organization. It doesn't explicitly name alternatives or exclusions, but the context signals and sibling list show many get_* tools; the description's focus on subscription/usage is clear enough to guide selection. A small gap: no explicit 'use this instead of X' 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description does not contradict them. The description adds little behavioral context beyond that, such as ordering or pagination, but the read-only/idempotent profile reduces the burden on 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 focused sentence stating the action, scope, and optional filters. There is no filler, and it does not redundantly repeat schema details.

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

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

For a simple read-only list operation with fully documented parameters and annotations covering safety, the definition is nearly complete. It lacks explicit return-shape or pagination details, but the low complexity makes those omissions non-critical.

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%, with each parameter already documented including enums, bounds, and a default for limit. The description only restates the high-level status and severity filters, so it does not add meaningful semantic value 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 identifies the resource (issues), the scope (a website), and the optional filters (status and severity). It is clear and unambiguous relative to sibling tools like list_sites and list_tasks, though it does not explicitly name a sibling to differentiate from.

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 this tool is used when an agent needs the issues belonging to a site and wants to optionally narrow by status or severity. It does not provide when-not-to-use guidance or name alternatives, so usage context is only implicit.

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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered; the description adds the useful detail that results are authorization-scoped to the signed-in user and enumerates which attributes come back. It does not mention ordering or result-size limits, which would be the remaining behavioral gaps.

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

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

Two sentences, no filler: the capability and its scope come first, then the sibling routing. Every sentence carries distinct information an agent needs.

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 does its job by listing the attributes returned (organization, platform, language) and the access scope. It could be slightly more complete by noting whether the full list is always returned or if there is any truncation, but for a zero-parameter read tool with rich annotations it is close to sufficient.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. Nothing in the description is needed to disambiguate an argument.

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 and resource ("List the websites") and scopes it to what the signed-in user can access, plus the fields returned (organization, platform, language). The second sentence explicitly separates it from get_portfolio and get_site_brief, so an agent can distinguish it from siblings without opening a schema.

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

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

Explicitly names the alternatives and the situation that calls for them ("For an overview with status and priorities, call get_portfolio first and get_site_brief per site"). That is clear routing guidance, though it reads as sequencing/complement rather than a hard exclusion, leaving mild ambiguity about whether list_sites should be skipped when an overview is wanted.

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?

Annotations already declare readOnly, idempotent, and non-open-world. The description adds meaningful behavior beyond that: derivedFrom tasks are blocked, appear last, and cannot be ordered, and the list includes fix and verification instructions.

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 scope and the sibling alternative are front-loaded and there is little waste. The middle sentence about fix and verification instructions is slightly loose, but the description remains compact and purposeful.

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 still explains the key non-obvious return semantics: derivedFrom blocking, ordering constraints, and included instruction content. Minor omissions around pagination and exact return shape are acceptable for a read-only 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?

Schema description coverage is 100%, so limit, locale, status, and site_id are already documented in the schema. The description adds no parameter-level detail, which is acceptable at baseline 3 when the schema does the heavy lifting.

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 and resource ('Full task list for a website') and distinguishes itself from the sibling get_site_brief, which it names explicitly. An agent can tell this is the list-all-tasks tool rather than a brief or a single-fix retrieval.

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?

Gives clear routing guidance: 'for the top 3 decisions call get_site_brief first', and notes that derivedFrom tasks cannot be ordered, which points toward order_fix limits. It lacks explicit when-not-to-use exclusions, but the alternative and its condition are stated.

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

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

Annotations provide no hints (all false), so the description carries the burden. It adds meaningful behavioral context: payment occurs only after the fix is proven, and it imposes role and subscription requirements. It does not repeat annotation info. It doesn't disclose side effects like whether the task status changes, but that's a minor gap for a purchase action.

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 plus a constraint clause. It front-loads the core action and immediately follows with the payment and access conditions. No fluff or redundancy.

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

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

For a simple 2-parameter action with full schema coverage and no output schema, the description covers the core purpose, payment model, and access prerequisites. It omits return-value details, but that is not critical for a purchase command. Overall, it is adequately complete 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 coverage is 100% and both parameters (task_id, note) have descriptions. The tool description adds no additional parameter semantics beyond what the schema already provides. Per the rubric, 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 verb ('Ask Vibeking to carry out') and the resource ('the fix for a task'), and distinguishes it from siblings like get_fix_catalog (which likely only lists fixes) and update_task_status (which updates status without ordering a fix). The purpose is 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 provides prerequisites (owners/admins only, active subscription) but does not explicitly state when to use this tool versus alternatives. It implies the tool is for ordering a fix, but it doesn't mention when to use get_fix_catalog to browse fixes first or when to use update_task_status instead. Usage context is present but not fully developed.

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?

Annotations only mark the operation as non-read-only and non-idempotent. The description adds useful behavioral details beyond that: it follows the Scan now path/page limits and returns either a run id or the refusal reason, which meaningfully informs an agent's expectation.

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

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

Two sentences with no filler. The action is stated first, then the return behavior, and the reference to the Scan now button adds practical context without redundancy.

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

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

For a single-parameter tool with no output schema, the description adequately covers what the call does and what it returns. The annotations cover the safety profile, and nothing essential for invoking this tool correctly is missing.

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

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

Schema description coverage is 100%: site_id is already documented as a UUID returned by list_sites. The description does not add parameter-specific details, 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 opens with a specific verb and resource: 'Start a crawl of a website'. It also gives operational scope ('same path and page limits as the Scan now button'), and this is the only start/scan action among the siblings, so it is clearly distinguished.

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 use case is clear: call this when you need to initiate a standard website crawl. It does not explicitly name alternatives or exclusion conditions, but no sibling provides an equivalent 'start scan' action, so the context is sufficient.

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

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

Annotations already convey read-write, idempotent, and non-destructive behavior, so the description does not need to restate those. It adds the 'fix task' scope and allowed statuses, though the enum is already in the schema; no side effects or transition rules are disclosed.

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

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

A single front-loaded sentence states the action, resource, and allowed values with no filler or redundancy. 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?

For a simple two-parameter update with complete schema coverage and annotations covering safety, the description is nearly sufficient. It does not describe the return value or error behavior, but no output schema exists and the operation is straightforward.

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%: both task_id and status are documented in the schema, including the enum and the origin of task_id. The description's parenthetical status list adds no information beyond the schema, so baseline 3 applies.

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

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

The description uses a specific verb ('Update'), names the resource ('status of a fix task'), and enumerates the four allowed statuses. This makes it immediately distinguishable from read-oriented siblings like list_tasks and get_fix_plan.

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

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

The description clearly implies the tool is for changing a fix task's status, but it does not explicitly state when to prefer it over alternatives or mention any exclusions. The sibling list makes the read/write distinction inferable, but the description leaves it implicit.

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