Empiria Local SEO

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

Annotations cover read-only, idempotent, non-destructive and closed-world, so the bar is lower; the description still adds real context beyond them. It discloses that denominators, failed attempts and unverified annotations are surfaced in the result, and that no AI calls are made and no semantic text evaluation occurs — a meaningful scope constraint telling the agent mentions/recommendations must arrive pre-annotated.

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

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

Four short sentences, front-loaded with what is computed, then the dimensions split, then result disclosures, then scope exclusions. No filler and no restatement of the title.

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, and the description partially compensates by naming the metrics and the denominator/failure/unverified reporting. However, for a tool taking up to 500 richly structured observation objects, it never explains the annotation contract — how mentioned/recommended booleans are validated, how citations are matched against owned_hosts, or what makes an annotation 'ungeprüft' — leaving an agent to guess at input correctness.

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 does so indirectly: 'annotierten Antwortprotokollen' maps to the observations array and 'eigene Quellen' (owned sources) maps to owned_hosts, giving both required parameters an inferable role. It adds nothing about the required per-observation fields (provider, surface, prompt_id, prompt, status), the enum semantics of status/location_access, or the verified/identity_verified flags.

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?

Names a specific verb ('Berechnet') and specific outputs (Nennungs-, Empfehlungs-, eigene Quellen- und Zitationsquoten) computed from a specific input class ('gelieferten annotierten Antwortprotokollen'). This separates it from siblings that fetch or produce data (analyze_web_performance, analyze_performance_export) by making clear it is a pure aggregation over already-supplied logs, though it never names the sibling it replaces.

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: an agent infers 'use this when you already have annotated observations'. The negative constraints ('Führt keine KI-Anfragen durch', 'beurteilt keine Texte semantisch') rule out misuse, but there is no explicit when-to-use statement, no prerequisites, and no named alternative among the siblings.

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

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

Annotations already establish read-only, idempotent, closed-world, non-destructive behavior, and the description adds meaningful constraints beyond them: duplicate-ID validation, summation of separated metrics, change calculation only under a comparable baseline, and explicit exclusion of account access and automatic AI-traffic/revenue attribution. It stops short of describing error behavior when baselines are not comparable.

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

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

Three compact sentences, front-loaded with the core validation/aggregation purpose, followed by constraints and limitations. Little waste, though the dense German nominal style reduces scannability slightly.

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 a two-parameter but heavily nested schema with no output schema and no field-level documentation, the description covers validation scope, aggregation behavior, and the comparison precondition reasonably well. It is still incomplete about expected output, failure modes on incomparable baselines, and the meaning of the many required metadata fields.

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

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

Schema description coverage is 0% and the schema is deeply nested, so the description bears most of the burden; it does clarify the semantics of `baseline` (comparison requires comparability) and references `definitions` and duplicate `id`s. It says nothing about required fields such as `source`, `timezone`, `period_start`/`period_end`, or the `currency` pattern, leaving significant gaps.

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 specific operations (validating exported GSC/GBP/CRM-like datasets, summing split metrics, computing changes against a baseline) rather than restating the title. It implicitly separates itself from live-account siblings via 'Kein Zugriff auf Konten', though it does not name any sibling explicitly.

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 rather than stated: 'gelieferte ... Datensätze' and 'Kein Zugriff auf Konten' signal that this tool is for offline export analysis, and the comparable-baseline condition hints at a prerequisite. However, there is no explicit when-to-use vs. when-not guidance relative to siblings like analyze_web_performance or compare_business_profiles.

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 annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real behavioral context beyond them: it does not perform measurements and does not compute a blanket SEO score, which prevents the agent from over-interpreting results. It still says nothing about how thresholds or findings are returned.

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 short sentences, front-loaded with the core split (lab vs. field) before the check and the negative scope statement. Every sentence carries information; only the SEO-score disclaimer is somewhat defensive, but it earns its place as a scope boundary.

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?

This is a complex tool with 10 parameters, nested objects and no output schema, so the description has to do more work. It covers the analytical behavior well but never describes the shape of the result (verdicts per metric? per resource?) or the role of the period/percentile fields, leaving the agent to infer how to assemble a full call.

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 carry the load. It does explain the meaning of several key inputs — kind (lab vs. field), device (per-device evaluation), metrics (LCP/INP/CLS p75) and resources (large resources in the trace) — but leaves source, observed_at, percentile, period_start and period_end entirely unexplained.

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 object: it splits lab vs. field data, checks supplied p75 field values per device against LCP/INP/CLS thresholds, and lists large resources in the supplied trace. That is concrete and distinguishes it from measurement tools via 'Führt keine Messung aus'. It does not explicitly differentiate itself from the closest sibling, analyze_performance_export, 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?

Usage is implied rather than stated: the repeated word 'geliefert' signals the tool only evaluates data the caller already holds, and 'Führt keine Messung aus' steers the agent away from audit/measurement tools. However, no alternative is named (e.g. analyze_performance_export or audit_website), and no prerequisites or when-not conditions are given explicitly.

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 safety (readOnly, idempotent, openWorld=false, non-destructive), yet the description adds real behavioral context: determinism tied to rule version, the not_tested convention for missing inputs, and the caveat that a DOM snapshot is not a browser test. These are non-obvious semantics an agent could not derive from the 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?

Three tight sentences with the core capability front-loaded and no filler. The determinism and not_tested clauses each add distinct information rather than restating the title.

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 14-parameter tool with deep nesting, zero schema descriptions and no output schema, the description is too thin: the largest input ('expected_business') and the results shape ('Befunde') are never characterized. An agent can grasp the concept but cannot confidently populate most of the schema from this text alone.

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% across 14 parameters, including large nested objects, so the description carries the full burden. It gestures at the snapshot families (HTTP, robots, sitemap, DOM/rendered_html) but explains nothing about expected_business, paid_link_urls, target_results, redirect_chain, related_pages, or observed_at, leaving most inputs semantically opaque.

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 specific verb ('Prüft') and resource ('geliefertes HTML und optionale HTTP-/robots-/Sitemap-/DOM-Snapshots') and pins the mode as 'ohne Netzwerkzugriff', which separates it from network-fetching siblings like audit_website. It never names an alternative tool outright, so the differentiation is inferred rather than explicit.

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 offline framing ('ohne Netzwerkzugriff', 'geliefertes HTML') implies when to use it: when the caller already holds snapshots rather than a live URL. There is no explicit statement of when to prefer audit_website or the analyze_* siblings instead, so usage is only implied.

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?

Beyond the readOnly/openWorld annotations, the description discloses hard operating limits (max six pages, 20 further internal targets, 45-second total budget), robots compliance for the audit crawler, and that no leads are stored. It also clarifies the request profile ('öffentliche GET-Abrufe'), which an agent needs in order to predict cost and side effects.

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

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

One dense, front-loaded paragraph: what is crawled, then limits, then exclusions and safety. Every clause carries information, though the prose could be split into scannable sentences for faster parsing.

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

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

A read-only crawler whose safety profile is already covered by annotations needs less, and the limits are well covered. But with no output schema and no hint of what the audit returns (findings, mismatches against expected_business), and with the nested object unexplained, an agent still cannot predict 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?

Schema description coverage is 0%, so the description carries the full burden. The stated caps of six pages and 20 internal targets effectively explain max_pages and max_link_checks maxima, but the large nested expected_business object (name, hours, phones, address, services, location_type, approved_website_urls) is never mentioned, leaving its purpose and effect on the audit entirely undocumented.

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

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

The description names a specific action and resource ('Begrenzter HTTP-Crawl einer öffentlichen Website') and enumerates exactly what is collected (HTML, Kontaktlinks, Schema, robots, Sitemap). It does not name a sibling, so an agent must infer on its own how this differs from audit_page_snapshot or analyze_web_performance.

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?

Scope exclusions ('Kein Browser oder echter Suchbot-Test; externe Buchungsseiten bleiben ungeprüft') implicitly tell the agent when this tool is not sufficient, which is useful. However, there is no explicit when-to-use statement and no explicit routing to the sibling tools that would handle browser rendering or performance analysis.

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/non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: it normalizes spelling and phone-number variants before comparing, and it explicitly disclaims live verification, ownership checks and truth validation of master data — all of which affect how results should be 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?

Two sentences, front-loaded with the core action and scope, then the normalization and disclaimer clauses. The field enumeration is long but each item corresponds to a real schema property; no filler sentences.

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, yet the description never indicates what the comparison returns — per-field mismatches, a diff report, match/mismatch flags — nor how many profiles can be compared at once. For a read-only diff tool with a deeply nested two-parameter schema, that leaves the agent guessing about result 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 0% and the schema is heavily nested (reference object plus a profiles array of objects), so the description must compensate. It does map its field list onto several schema properties (phones, public_address, hours, service_areas, categories, services), which helps, but it says nothing about the reference/profiles split, profile_id, observed_at, or the 50-item cap on profiles.

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 ("Vergleicht") and both operands (supplied profile/directory data vs. approved master data), then enumerates the compared fields: name, phones, public address, location URL, hours, areas, categories, services. This makes it unmistakably distinct from siblings such as analyze_web_performance or summarize_local_competitors, which do not diff supplied data against a reference record.

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 states the task context (comparing supplied data against approved master data) and adds explicit exclusions: it does not check the Google profile live, ownership, or the truth of the master data. What is missing is routing guidance to an alternative tool for the live/verification cases it excludes.

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 establish read-only and idempotent, and the description usefully adds output semantics: prices are provisional net fixed prices, there are no hourly figures, no ranking or schedule commitment, and a binding offer only follows a review. That is real behavioral context beyond the annotations, though it leaves open how a warning confirmation is actually performed, since the schema exposes no confirmation field.

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, front-loaded with what is produced, followed by scope disclaimers. Every sentence carries information, though the confirm-warnings sentence is terse enough to be ambiguous.

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, idempotent estimator with no output schema, the description covers input source, output shape (provisional net fixed price, limited scope), what is explicitly not returned (hours, ranking, dates), and the binding-offer caveat. The remaining gap, the confirmation mechanism, is a schema-side omission rather than a description failure.

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% for a single array-of-objects parameter, so the description carries the burden and only partially does so: it says inputs are check rule IDs, but never explains the status field (fail/warn/pass/info/not_tested) or how statuses affect pricing and the warning-confirmation requirement. Nested structure and enum semantics remain undocumented.

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 (ableiten) and a specific output (Leistungspakete mit vorläufigem Netto-Festpreis und begrenztem Umfang) from a specific input (gelieferte Prüfregel-IDs). This clearly separates it from audit_*/analyze_* siblings, though it never names the closest alternative, get_check_catalog, which is where the check IDs come 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?

Implies the precondition (you must already have check rule IDs/findings) and states a process rule (Warnungen müssen bestätigt werden), but gives no explicit when-to-use vs. when-not guidance and never points to a sibling such as get_check_catalog for obtaining the IDs. Usage is inferable rather than 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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine context that the rules are deterministic and bundled with their skill origin and sources, but says nothing about catalog size, whether it is static/cached, or how limits are expressed.

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 noun-phrase sentence with no filler, and the identifying content (deterministic rules) is front-loaded. It would be marginally stronger as a full clause stating the action, but nothing is redundant.

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

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

For a zero-parameter, read-only catalog with no output schema, the description supplies what matters: it enumerates the attributes returned (version, skill origin, sources, check limits). An agent knows what it will receive and can proceed without further detail.

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 the baseline is 4; there is nothing for the description to disambiguate. It correctly does not waste words describing nonexistent 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 names a specific resource ("deterministische Regeln") and scope (catalog), and enumerates the fields the listing carries: version, skill origin, sources, and check limits. This clearly separates it from the analyze_*/audit_* siblings, which run checks rather than enumerate the rule set, though no sibling is named explicitly.

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 states what is listed but never says when to call it — e.g. before an audit to learn which rules apply or to read "Prüfgrenzen" before interpreting results. No alternatives or exclusions are given; the usage is only inferable from the word "Liste".

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/destructiveHint=false and a closed-world scope, so the safety profile is covered. The description adds real value by clarifying that statistics are computed only over *vorhandener* (present) values and that provenance/duplicate-ID checking is part of the behavior. It does not say whether duplicates cause rejection or deduplication, nor what the result looks like.

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 dense sentences with no filler: capability statement first, capability exclusions second. Every clause carries information an agent cannot get from the schema or annotations.

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 a nested two-object schema, no output schema and zero field documentation, the description covers purpose and exclusions but leaves the input contract largely unexplained. The most consequential ambiguity — whether duplicate or missing-provenance entries abort the call or are silently handled — remains unresolved.

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

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

Schema description coverage is 0% and all field names are undocumented, yet the description only hints that rating and review_count feed the aggregation. The four required context fields (service, search_location, surface, observed_at) and their role as provenance inputs are never explained, nor is how id/observed_at are validated.

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+resource combination: it validates the provenance and duplicate IDs of a *supplied* local competitor dataset and computes min/median/max over the ratings and review counts present in it. That distinguishes it reasonably well from data-gathering siblings, though the boundary against compare_business_profiles is not drawn explicitly.

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

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

It gives explicit negative scope — no live Maps query, no review-authenticity check, no claim about the market minimum — which steers an agent away from misusing it. What is missing is positive routing: it never names which sibling to use when a live lookup or a profile comparison is actually wanted.

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