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

Annotations already declare readOnlyHint=true, so the agent knows this is a safe read with no side effects. The description adds no further behavioral context (no auth requirement, no error/not-found behavior, no rate limits), but with annotations covering safety the lower bar makes a 3 reasonable.

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 short sentence with no waste, and the resource and lookup key are front-loaded. Nothing is padded, though there is little content to 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?

For a one-parameter read-only tool this is close to sufficient, but with no output schema the description doesn't hint at what 'details' are returned or what happens on an unknown id. Minor but real gaps remain for an agent deciding between this and get_live_stream_urls.

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 camera_id is already documented in the schema (albeit thinly as 'Camera id'). The description only restates that lookup is 'by id' and adds no format or range detail, 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 states a clear verb+resource ('Get details for a single camera') and scopes it by id, which distinguishes it from list_cameras and get_camera_count. It does not name a sibling explicitly, but the singular 'single camera by id' framing makes the distinction inferable.

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 guidance and no mention of alternatives such as list_cameras or get_live_stream_urls. The only cue is the implicit singular-vs-plural contrast with the sibling list tool, which is left for the agent to infer.

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 readOnlyHint=true annotation already declares this is a safe read operation. The description adds the meaningful scope detail that only enabled cameras are counted, but says nothing about return format, org scoping requirements, or any filtering 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?

A single front-loaded sentence with no filler; every word contributes to the 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?

For a parameterless read-only counter with no output schema, the description communicates the essential scope (enabled cameras in the organization). Nothing critical is missing, though a note on how the count is scoped or returned would fully close the gap.

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?

Zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate beyond the fact that the count is implicitly org-wide.

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 (Get) and resource (number of cameras) with a clear scope qualifier (enabled, in the organization). It is distinguishable from list_cameras and get_camera by returning a count rather than records, though it does not explicitly contrast with those siblings.

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

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

No guidance on when to use this instead of list_cameras or get_camera. The counting intent is inferable from the description, but there are no explicit conditions or alternatives named.

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 readOnlyHint annotation already establishes this is a non-mutating read, so the description's burden is lighter. It adds that results include both 'events and summary', hinting at the return shape, but says nothing about result volume, pagination, or how the optional daily window/threshold settings affect output.

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 that names the action, the target resource, the analytical dimensions, and the temporal scope. No filler, no restatement of the tool name.

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 an 8-parameter analytical tool with no output schema and only a readOnlyHint annotation, the description covers the core query dimensions but omits the optional threshold/time-window semantics and any sense of result shape. Adequate to call the tool, but not complete enough to predict behavior.

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

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

Schema description coverage is 75%, and the description restates the metric and entity value sets ('counting, idle, presence of people, vehicles, forklifts') which duplicate the enums rather than adding meaning. It offers no help on the three undocumented/optional params (threshold, start_time, end_time) or the RFC3339 date format, so it neither compensates for nor adds 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 gives a specific verb+resource ('Get intelligence events and summary for a camera') and enumerates the metric and entity dimensions the tool covers, so an agent knows exactly what data comes back. It stops short of distinguishing itself from siblings like get_lpr_report or get_zones, which also return per-camera analytical output.

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 by the scope statement ('for a camera ... over a date range'), but there is no explicit when-to-use vs when-not, and no routing guidance against siblings such as get_lpr_report or get_camera_count. The agent must infer that 'intelligence' means the counting/idle/presence analytics family.

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?

readOnlyHint=true already declares the safety profile, so 'modifies nothing' is largely reinforcement, though it does confirm the annotation explicitly. 'For the authenticated caller' adds genuine auth-scoping context that the annotation does not cover. However, nothing is said about URL lifetime/expiry or whether the stream is continuous, which matters for a stream-URL tool.

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

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

Two short sentences, zero filler, with the core action front-loaded and the read-only guarantee placed immediately after. Every clause 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 one-parameter read tool with no output schema and annotations covering safety, the description is nearly sufficient. The only notable gap is the absence of any note on URL validity or output shape, which would help an agent that must act on the returned URL.

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 the single parameter is fully documented in the schema, including the 1-to-4 constraint. The description's 'up to 4 cameras' only restates the maxItems bound, adding no syntax or format detail beyond the schema. 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 and resource ('Get a URL to a live stream of up to 4 cameras'), which is clearly distinct from siblings like get_camera, list_cameras, or get_camera_count that return metadata rather than stream URLs. It does not explicitly name a sibling, 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 phrase 'for the authenticated caller' implies the calling context, but there is no explicit when-to-use guidance, no mention of when this is preferable to get_camera, and no prerequisites or exclusions stated. Usage must be inferred.

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, so safety is covered structurally. The description adds nothing behavioral beyond re-stating that the camera must be LPR-enabled (already in the schema), and says nothing about report contents, time-range defaults, pagination, or error behavior when the camera is not LPR-enabled.

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 with no filler or redundancy. It is efficient, though its brevity leaves the definition thin overall rather than being a model of informative concision.

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 report tool with no output schema, the definition should at least sketch what the report returns or how the verbatim 'query' passthrough is used. Annotations and the 100%-covered schema carry params and safety, but the report's nature remains unspecified.

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 both camera_id and the opaque 'query' passthrough object are already documented in the schema. The description contributes no additional parameter meaning, which is the expected baseline when the schema does the work.

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

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

The description names a specific verb and resource ('Get the license-plate-recognition report') tied to an LPR-enabled camera, which is more specific than the generic siblings like get_camera or get_intelligence. It does not explicitly contrast itself with any sibling, 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 'LPR-enabled camera' qualifier implies the precondition for use, but the description never states when to choose this tool over get_intelligence, get_camera, or the other siblings. Usage is only implied, not directed.

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, so the safety profile is covered by structured data. The description adds nothing beyond the bare purpose — no pagination behavior, no ordering, no indication of what happens when the camera has no zones. With annotations present the bar is lower, but this adds essentially zero 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?

A single, front-loaded sentence with no filler. Nothing is wasted, though there is also very little there.

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 single-param read tool with annotations covering safety, this is close to adequate, but with no output schema the agent gets no hint of what a 'zone' record contains or how many are returned. A brief note on the return shape would close the gap.

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?

Only one parameter, and the schema documents it at 100% coverage ('Camera id'), so the baseline of 3 applies. The description contributes no extra meaning about the camera_id — e.g. whether it comes from list_cameras.

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?

Clear specific verb ('List') plus resource ('zones defined on a camera'), so the agent knows exactly what it returns. It does not, however, differentiate itself from siblings like get_camera or get_live_stream_urls beyond the resource name.

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 guidance, no prerequisites, and no mention of any alternative tool. The agent must infer that this is the zone-listing counterpart to get_camera purely from the resource name.

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, so the safety profile is covered. The description adds that results are paginated via cursor, which is genuine behavioral context, but omits ordering, default page size, or what happens when the cursor is omitted.

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 short sentences, both front-loaded with the essential information and zero filler. Nothing could be trimmed 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?

For a simple paginated read tool with fully documented parameters and a clear readOnly annotation, the description covers purpose and pagination adequately. Slightly more on defaults/ordering would make it fully complete, but nothing critical 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 coverage is 100%, so both parameters are already documented in the schema (limit as max results per page, cursor as coming from a previous response's 'next' field). The description only restates the cursor pagination idea, adding nothing beyond the schema; 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 and resource ('List appliances') and even disambiguates the domain acronym as Intelligent Video Recorders for the org. It is clear what the tool returns, though it does not contrast itself against the sibling list_* 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 gives scope ('for the org') but no guidance on when to choose this over siblings like list_cameras or list_locations, nor any prerequisites. Usage is only implied by the name.

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 cover the read-only safety profile, and the description adds value beyond them: it discloses org-wide scope, the exact fields returned, and the cursor-based pagination mechanism. It does not mention auth requirements or rate limits, but the added context is solid.

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

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

Two short sentences, front-loaded with what is listed and what comes back, then the pagination model. No filler.

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

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

With no output schema, the field enumeration is important and present, and pagination is explained, which is what an agent needs to iterate pages. Minor gap: no note on default page size or ordering.

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 limit and cursor are already documented in the schema, including the cursor's origin in the 'next' field. The description's pagination note adds nothing 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?

States a specific verb+resource ('List cameras') plus org scope and enumerates the returned fields. It does not distinguish itself from siblings like get_camera or get_camera_count, which an agent must infer.

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

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

No when-to-use guidance and no mention of alternatives such as get_camera (single) or get_camera_count (aggregate). The name implies enumeration for the org, but nothing states when this tool is preferred over its 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 declare readOnlyHint=true, so safety is covered. The description adds real value beyond that by disclosing the return shape (id and name only) and the exact pagination contract – pass the response's 'next' back as 'cursor' until null. That is behavior an agent cannot infer 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?

Two sentences, both front-loaded: what it returns first, pagination protocol second. No filler, no redundant restatement of the tool name.

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 compensates by naming the returned fields and the pagination loop, and annotations cover the read-only safety profile. Nothing essential for a correct call 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 coverage is 100% on both parameters, so the baseline is 3. The description goes further by explaining the cursor's role in the pagination loop ('pass the response's next value back as cursor until it is null'), which matters because there is no output schema documenting the 'next' field.

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 locations') plus the access scope ('the API key has access to') and the returned fields (id, name). It does not name any sibling, but the resource is distinct from the camera/appliance/zone siblings, so an agent can still select it correctly.

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

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

The description implies usage (list the locations your key can see) and gives operating instructions for pagination, but it never states when to prefer this over get_camera, list_cameras, or other discovery tools. No exclusions or alternatives are offered.

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 readOnlyHint annotation already declares the safety profile, and the description mainly reinforces it with 'Only GET is supported; this server is read-only.' It adds a useful docs URL and example path, but says nothing about auth requirements, rate limits, error behavior, or what the response contains beyond the raw API response.

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?

Every sentence earns its place: the purpose and scope come first, followed immediately by an example and the key constraint. There is no 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?

Given a generic GET tool with no output schema and readOnly annotations, the description provides enough to invoke it correctly by pointing to the API documentation, giving a path example, and stating that only GET is allowed. It could be stronger by noting the expected response shape or how errors are returned, but the docs link covers most unknowns.

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 already defines the path prefix and query format. The description adds a concrete example path (/v1/integrations), which gives the agent a useful pattern beyond the schema's abstract constraints, though it does not add meaning for the query parameter.

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

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

The description states a specific verb and resource ('perform a GET against any documented Spot AI API path') and identifies itself as an 'Escape hatch,' which distinguishes it from the specific endpoint tools among its siblings. The example path and constraint ('Only GET is supported') further pin down exactly what the tool does.

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 'Escape hatch' framing implies this is for endpoints not covered by dedicated tools, and the docs link tells the agent where to find valid paths. However, it never explicitly names when to prefer a sibling tool or when not to use this generic endpoint, so it falls short of full when/when-not guidance.

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