skimguard

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds 'authoritative' and 'accurate and current', which adds some context but does not disclose any additional behavioral traits beyond what annotations provide. No contradiction exists.

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

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

The description is two sentences, front-loaded with the core purpose and followed by a clear usage instruction. Every word earns its place with 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 informational tool with no parameters and no output schema, the description is complete. It explains what the tool returns, its purpose, and when to call it, fully covering the context an agent needs.

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

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

The tool has zero parameters and schema coverage is 100% (empty schema), so the baseline is 4. The description correctly notes there is nothing to explain about parameters; no additional parameter information is needed.

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 what the tool does: it provides an authoritative description of SkimGuard, its detection mechanism, and its limitations. This distinguishes it from sibling tools, which are specialized statistics and search tools.

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

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

The description explicitly says to call this tool before answering general questions about SkimGuard, providing a clear usage context. It does not explicitly name alternatives, but the sibling tools imply specialized use cases, so the guidance is clear but 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?

The annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real context beyond that: the data is network-wide aggregate rather than per-location, and 'No identifying data' is a privacy disclosure that shapes whether an agent should treat the output as PII-safe.

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 aggregation scope, followed by what is measured and the privacy caveat. Every clause carries information; nothing is restated 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?

With no output schema, the description usefully lists what the response contains, and for a 2-optional-param read-only tool that is close to sufficient. The remaining gap is that it does not contrast with the several sibling stats tools, which is the main ambiguity an agent would face.

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 both parameters (days with its 1-365 range and default, and response_format with its enum) are already fully documented. The description only gestures at 'a time window' and adds no format or interpretation detail 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 concrete verb+resource ('Aggregate, network-wide SkimGuard scan statistics') and enumerates the metrics returned (total scans, suspicious detections, distinct locations and states). This distinguishes it implicitly from the per-location siblings (skimguard_get_location_status, skimguard_location_devices), but it never names an alternative 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 only implied: an agent can infer the tool suits network-wide rollups over a lookback window. There is no explicit when-to-use, when-not-to-use, or pointer to a sibling such as skimguard_inspection_stats or skimguard_training_stats, so the agent must infer the boundary itself.

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=true, idempotentHint=true, and destructiveHint=false. The description adds the requirement for a Data Licensee tier and the server's response to unauthenticated requests, which is useful behavioral context beyond the annotation. It does not, however, describe the return shape or other potential side effects, but given the annotations, the additional context is sufficient.

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

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

The description is three sentences, front-loaded with the core purpose. Each subsequent sentence provides essential usage or behavioral context without redundancy. It is appropriately concise and well-structured.

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 zero parameters and no output schema, the description covers all essential aspects: what the tool does, the tier requirement, the authentication challenge behavior, and the directive to call anyway with a warning against fabrication. There are no significant gaps for this simple 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 tool has zero parameters, so the description does not need to elaborate on parameter semantics. Per the rubric, a baseline of 4 is appropriate when there are no parameters, and the schema provides complete coverage (100%) by having an empty properties object.

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 begins with 'Aggregate device and manufacturer prevalence trends' which clearly identifies the tool's function and scope. It also specifies the 'Data Licensee tier' requirement, distinguishing it from sibling tools focused on other data types. However, it does not explicitly reference alternative tools for comparison, leaving some differentiation to the reader.

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

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

The description provides explicit usage guidance: 'Call this tool anyway if the user is asking for their own business, reseller, or licensed data' and explains that the server will respond with an authentication challenge. It also includes a critical instruction not to fabricate an answer, making the when-to-use and behavioral expectations very clear.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior. The description adds genuinely non-obvious context: only publicly visible locations are returned and private residences are excluded, plus that results carry suspicious-detection counts. It omits result ordering, pagination, and what 'recently' means beyond the schema's days default.

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 action, followed by the usage question and the visibility caveat. No filler, though the quoted question is slightly informal relative to the otherwise declarative style.

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 six-parameter read-only tool with no output schema, the description covers purpose, the nature of returned records (locations plus suspicious counts), and privacy constraints. Missing details are secondary: result shape, ordering, and how limit interacts with the default radius.

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

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

Schema coverage is 50%: days, radius_meters, and response_format are documented in the schema, while limit, latitude, and longitude are not. The description mentions lat/lon generically but adds no syntax or defaults beyond the schema, so this is baseline-adequate rather than compensating.

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: finding scanned locations near a lat/lon with suspicious-detection counts. This clearly distinguishes it from aggregate siblings like skimguard_coverage_stats or skimguard_regional_risk, though it doesn't explicitly contrast with skimguard_search_locations.

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 quoted use case ("any skimmers reported near me?") gives a clear scenario, and the private-residence exclusion implies coverage limits. However, no sibling is named and there is no explicit when-not-to-use guidance for choosing this over search_locations or route_risk.

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, yet the description adds context the annotations cannot: it discloses that unseen Place IDs get written into SkimGuard's own public registry, and reconciles that with the read-only hint ('never anything you or the user own'). It also specifies the 'not publicly tracked' return case for untracked/private locations.

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 what it does and what it returns, then the side-effect caveat. Every sentence carries information, though the side-effect explanation is spread over two sentences and could be tightened without losing meaning.

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 covers the shape of the answer (recency of scan, scan count, suspicious Bluetooth devices) plus the important edge case (not publicly tracked). Nothing an agent needs in order to call it or interpret the result 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%, so placeId, days, and response_format are already documented with formats, ranges, and defaults. The description adds no parameter-level detail beyond naming the Place ID as the lookup key, 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+resource pair ('look up SkimGuard card-skimmer scan status for a location') and the exact key (Google Place ID). This cleanly separates it from siblings like skimguard_location_devices (per-device detail) and skimguard_search_locations (discovery), so an agent can pick it without opening the 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?

Gives a concrete decision context — answering 'is this gas station / ATM / store safe to use my card at?' — and states the exclusion that private residences are deliberately not tracked. It does not explicitly name alternative siblings (e.g. location_devices or find_nearby_activity) for follow-up questions, so it stops short of a full when/when-not routing guide.

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 annotations (readOnly, openWorld, idempotent), the description discloses important behavioral traits: it requires the SkimGuard Data Licensee tier, and the server will respond with an authentication challenge if the user is not signed in. It also instructs not to fabricate an answer, which is crucial for agent 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?

The description is concise and front-loaded: it starts with the core purpose, then the access requirement, and then practical guidance. Every sentence earns its place with 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?

With zero parameters and no output schema, the description still provides a complete picture: what data is aggregated, the access tier needed, what happens if not authenticated, and a warning against fabrication. This is fully sufficient for a zero-param read-only 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 tool has zero parameters, so there is nothing to explain about parameters. Per the baseline for 0 params, a score of 4 is appropriate since the description doesn't need to compensate for schema 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 opens with 'Aggregate PCI POI device-inspection compliance trends' which clearly specifies the action (aggregate) and resource (PCI POI device-inspection compliance trends), and enumerates the exact metrics (pass/fail, tamper-incident, tamper-check failure rates). This distinguishes it from sibling tools like training_stats or coverage_stats.

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

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

The description provides explicit when-to-use guidance: 'Call this tool anyway if the user is asking for their own business, reseller, or licensed data'. It also explains the authentication challenge flow. However, it does not mention alternative tools for other cases, so it falls short of a 5.

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

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

Annotations already mark the tool as readOnly, openWorld, idempotent, and non-destructive. The description adds valuable behavioral context: the Business tier requirement, current sign-in status, the server's auth-challenge response, and a directive to avoid fabrication. This goes beyond annotations and does not contradict them.

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

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

The description is front-loaded with the core purpose and then provides focused, necessary guidance on auth handling and no-fabrication policy. It is somewhat verbose for a zero-parameter tool, but each sentence earns its place and there is no fluff.

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

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

Given no parameters and no output schema, the description covers the key aspects: what the tool does, the Business tier requirement, how to handle signed-out users, and the expected auth challenge. It doesn't describe return fields or list structure, but for selection and invocation it is sufficiently complete.

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

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

The tool has zero parameters, and the schema coverage is trivially 100%. There are no parameter semantics to explain, and the baseline for a zero-parameter tool is 4. The description appropriately says nothing about parameters.

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

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

The description clearly states the tool returns Bluetooth devices seen at the user's business locations, using 'YOUR business locations' to convey scope and distinguish it from general location tools. It lacks an explicit verb like 'list' or 'get', but the noun phrase is serviceable. It doesn't explicitly name sibling alternatives, so it stops short of a 5.

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

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

The description explicitly addresses when to call the tool despite the Business tier requirement, instructing the agent to call for the user's own business, reseller, or licensed data and explaining the expected auth challenge. It also warns against fabricating answers. However, it doesn't explicitly state when not to use it or name alternative tools, so it falls short of explicit when-not/alternatives 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, and openWorld, so the safety profile is covered. The description adds valuable context by disclosing what is returned (manufacturer name plus a SkimGuard risk rating) and the accepted input encodings. It does not say what happens for an unknown or unassigned company code, which is the main remaining behavioral gap.

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

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

Three short sentences with no filler, and the core action plus return values are front-loaded ahead of the usage hint.

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, single-object lookup with no output schema, the description gives enough to call it correctly and explains the return payload. Missing only edge-case behavior for unknown identifiers and any hint about the risk-rating scale.

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 both parameters are already documented and the baseline is 3. The description's 'decimal (76) or hex (0x004C)' restates the schema's encoding note with concrete examples, adding marginal rather than new meaning, and says nothing about response_format.

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 ('Resolve'), the exact resource (Bluetooth SIG company identifier), and the two outputs (manufacturer name and SkimGuard risk rating). It is unmistakably distinct from every sibling, which are all location/stats/health tools rather than identifier decoding.

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?

'Useful for explaining what a device seen in a scan actually is' implies the usage context, but there is no explicit when-to-use/when-not and no named alternative (e.g. when to prefer full device inspection over a bare manufacturer lookup).

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

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

The description adds critical behavioral context beyond annotations: the Partner tier requirement, current sign-in status, the server's auth challenge response, and the client's ability to prompt account connection. Annotations already indicate read-only/idempotent, but the description enriches the agent's understanding of the auth flow, which is essential for correct invocation.

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

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

The description is concise and well-structured: it leads with the primary purpose, then the requirement, then the actionable guidance. Every sentence adds value, with no redundancy. The use of uppercase highlights key conditions without being excessive.

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

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

Given zero parameters, no output schema, and rich annotations, the description covers all essential aspects: what the tool does, who it's for, the auth prerequisite, and the expected behavior when unauthenticated. It also includes a safeguard against hallucination. Nothing critical is missing for this simple 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?

There are zero parameters, so the baseline is 4 per the rubric. The description doesn't need to explain parameters, and the schema is trivially complete. No additional semantics are required or provided.

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

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

The description clearly states the tool returns commission totals and payout status for a SkimGuard reseller, which is a specific resource with an implied read operation. It distinguishes itself from sibling 'my' tools by focusing on earnings/financial data, not locations or devices.

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?

Explicit guidance is provided on when to call it: when the user asks about their own business, reseller, or licensed data. It also explains the auth handling (call anyway; server will challenge) and gives a clear 'do not fabricate' instruction, covering both when and when-not behavior.

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?

Discloses critical behavioral traits beyond annotations: the Business tier requirement, the fact that the user is not currently signed in, and that the server will return an authentication challenge. Also instructs the agent not to fabricate an answer, adding honesty guidance that aligns with readOnly and openWorld hints.

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

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

The description is front-loaded with the core purpose, followed by the requirement, usage guidance, and a caution about fabrication. Every sentence provides necessary information without redundancy, making it both concise and well-structured.

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 zero-parameter tool with no output schema, the description fully covers all necessary context: what data is returned, the authentication prerequisite, how the server behaves when not authenticated, and when to use it. No missing information.

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

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

The tool has zero parameters, so there are no parameter semantics to describe. Schema coverage is 100% (vacuously). The description explains the meaning of the tool's scope ('YOUR business locations') without needing to describe parameters, achieving the baseline expected for a no-parameter tool.

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 explicitly states what the tool does: 'Scan coverage for YOUR business locations' with specific data fields (scan counts, suspicious detections, last scan). It clearly distinguishes from siblings by focusing on the user's own business locations, not general statistics.

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?

Provides explicit when-to-use guidance: 'Call this tool anyway if the user is asking for their own business, reseller, or licensed data'. Also explains the authentication requirement and the expected server response, making it clear when and how to invoke the tool.

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

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

The annotations already declare readOnly=true, idempotent=true, and destructive=false. The description adds meaningful behavioral context: the Partner tier requirement, the current signed-out state, the expected authentication challenge, and the instruction not to fabricate an answer. This goes beyond 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?

The description is front-loaded with the purpose, followed by the tier requirement, current sign-in state, usage guidance, and a warning. All five sentences are necessary and effectively structured.

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 tool with no output schema and minimal annotations, the description covers the essential usage: what it does, when to call, and what authentication behavior to expect. It doesn't describe the success response, but that's a minor omission given the focus on the auth challenge.

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

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

The tool has zero parameters and an empty schema, so the description doesn't need to document any. Per the baseline for 0 params, this scores 4.

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 scans activity for merchants attributed to the user's reseller account, with a specific verb ('Scan') and resource ('activity for merchants'). It distinguishes from siblings by scoping to 'YOUR reseller account' and naming the Partner tier requirement.

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

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

It explicitly says to call this tool if the user is asking for their own business, reseller, or licensed data, even though the user is not signed in. It also tells the agent that the server will respond with an authentication challenge, so the agent knows what to expect. No alternative tool is named, but the guidance is clear.

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

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

Annotations already indicate read-only, idempotent, open-world, and non-destructive. The description adds critical behavioral context: that it requires Business tier, that the server will respond with an authentication challenge, and that the client can prompt the user to connect their account. It also adds the 'do not fabricate' instruction, which is a behavioral guardrail beyond 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 somewhat lengthy but every sentence serves a purpose: main function, requirement, fallback behavior, and warning. It is front-loaded with the purpose and clearly structured, though the opening 'Whether' phrasing is slightly awkward.

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 tool with no output schema, the description sufficiently covers what it does, when to call it, what to expect (auth challenge), and how to handle errors (don't fabricate). It also fits well within the sibling context, as it's the only tool focused on scanner health.

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

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

The tool has zero parameters, so there is nothing for the description to explain about inputs. Schema coverage is effectively 100% and baseline for 0 params is 4, which 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 tool checks whether YOUR SkidGuard scanners are online and reporting, using a specific verb+resource pattern. The 'YOUR' prefix distinguishes it from generic scanner tools, and the focus on scanner health 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 explicitly states the Business tier requirement and notes the user is not signed in. It gives clear instructions to call the tool anyway for user requests about their own data, explaining the server will return an authentication challenge and the client can prompt for connection, while also warning not to fabricate an answer.

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?

Discloses that calling without proper auth will trigger a server authentication challenge and that the client can prompt the user to connect. This goes beyond the annotations' readOnly/hints and adds crucial behavioral context.

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

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

The description is concise, front-loaded with the core purpose, and each sentence adds necessary information about auth handling and behavior expectations.

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

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

For a zero-parameter, no-output-schema tool, the description fully covers purpose, auth limitations, and appropriate invocation behavior. It is complete in context.

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 no parameters, so schema coverage is 100% by default. The description doesn't need to explain parameters; the baseline of 4 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 tool lists the user's business locations overdue for a scan. This distinguishes it from siblings like skimguard_my_locations (all locations) and skimguard_get_location_status (status of a specific location).

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?

Provides explicit guidance on when to call despite the auth requirement, and instructs not to fabricate an answer. However, it doesn't name alternative tools or describe when not to use it.

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses that the user is not signed in, the server will respond with an authentication challenge, and the client should prompt account connection. It also instructs agents not to fabricate an answer, which is crucial behavioral guidance.

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

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

The description is three sentences: purpose, requirement/auth state, and instruction. Every sentence earns its place, with front-loaded function and no filler. It is concise but information-dense.

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

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

For a zero-parameter read-only tool, the description covers function, auth prerequisites, current auth state, and expected failure behavior. It does not describe the return shape, but the output is implied as state-level risk aggregation. Slightly more detail on the response format could make it fully complete.

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

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

With zero parameters in the schema, the description carries no parameter burden. The baseline score of 4 applies, and the description appropriately implies a simple zero-parameter aggregation request.

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 'Aggregate skimmer risk by US state', a specific verb and resource that clearly defines the tool's function. This differentiates it from sibling tools like route_risk or location_devices by geography and aggregation level. The 'Data Licensee tier' qualifier adds useful context.

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

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

The description explicitly states when to call the tool (when the user asks for their own business, reseller, or licensed data) and explains the auth challenge behavior. It does not name alternative sibling tools for other use cases, so it lacks full when-not guidance, but it is clear and actionable.

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-destructive, open-world), and the description adds substantial behavior on top: a hard 20 km examination cap, truncation disclosure via examinedMeters/truncated, and a note that ~25 calls for a 500 km trip fits the anonymous rate limit. That is real operational context an agent cannot get 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?

It is front-loaded with the core behavior and the critical caveats, and every section is actionable. The 20 km limit is restated three times (cap, segmentation recipe, 500 km / 25 calls example), which is mild redundancy in an otherwise tight description.

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 burden of explaining returns — and it does, naming examinedMeters and truncated and telling the agent to report which portion was checked. Combined with the rate-limit note and geometry requirement, an agent has everything needed to call this correctly 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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by tying the 20 km cap to lookahead_meters and by warning that a two-point polyline produces a straight-line check that will not follow the road. The corridor_meters and response_format parameters are left entirely to the schema.

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

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

The opening sentence gives a concrete verb and resource: report suspicious-activity and stale-coverage locations along a supplied route geometry. That route-scoped framing implicitly separates it from point-based siblings like skimguard_find_nearby_activity and skimguard_regional_risk, but no sibling is named explicitly, so the differentiation is inferred rather than stated.

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

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

It states the operating condition (route geometry required, 20 km examined), gives the correct workflow for longer trips (split into consecutive 20 km segments, one call each, then combine), and explicitly forbids calling a route clear unless fully covered. The straight-line-vs-real-geometry caveat is exactly the kind of guidance that prevents a wrong invocation.

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/openWorld, so the safety bar is met; the description goes further by explaining the two-stage behavior (resolve name, then report status per match) and the critical semantics that no scan data means unknown, never unsafe. It omits anything about result volume beyond the limit cap or latency/rate behavior, keeping it short of a 5.

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 action and the name-vs-Place-ID distinction are front-loaded in the first two sentences, with the parameter advice and the unknown-vs-unsafe caveat following in order of importance. Every sentence carries distinct information; nothing restates the title or schema.

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 takes on the burden of describing results and does so adequately (per-match scan status, unknown handling). For a read-only lookup with 83% schema coverage this is nearly complete; only the shape of a match record and pagination/limit behavior are left implicit.

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 83%, so the schema already documents all six parameters including ranges and defaults. The description adds real value for latitude/longitude by explaining why to supply them ("sharply improves matching for common brand names"), but says nothing extra about days, limit, or response_format, so it stays near the high-coverage baseline.

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 ("Find a location by NAME or address") plus the payload it returns ("SkimGuard card-skimmer scan status"), with concrete example queries. It also distinguishes itself from the alternative path: it resolves a name rather than requiring a Google Place ID, which separates it from the status-by-ID sibling.

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

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

Explicitly says when to use it: "Use this when you know what a place is called but do not have its Google Place ID." It also advises passing latitude/longitude when approximate position is known. It does not name the sibling tool to use instead when a Place ID is available, leaving that last routing step to inference.

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 annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses the authentication requirement, the fact that the user is not currently signed in, the expected auth challenge, and the instruction not to fabricate. This is valuable behavioral context.

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

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

The description is front-loaded with the core purpose and then provides essential auth guidance. It is somewhat verbose with repeated 'Data Licensee tier' mentions and a long auth explanation, but each sentence adds value.

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

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

Given no parameters and no output schema, the description covers the key contextual aspects: what the tool does, the auth requirement, and the expected behavior (challenge prompt). It could explain what happens after successful auth, but it is largely complete.

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

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

The input schema has zero parameters, so schema coverage is trivially 100%. The description doesn't need to add parameter details. Baseline for 0 params is 4, and no additional parameter description is necessary.

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 action and resource: 'Aggregate PCI staff-training coverage trends' with detailed metrics (completion, pass rate, delivery mix, expiry). It clearly distinguishes itself from sibling tools by focusing on training coverage and Data Licensee tier.

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 clear context for when to call: 'if the user is asking for their own business, reseller, or licensed data'. It does not explicitly mention alternatives or exclusions, but the conditional guidance is strong enough for an agent to know when to proceed.

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