Server Quality Checklist

Tool Scores

• list_alertsA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full transparency burden. It discloses that results are ordered newest-first, that 'date' is in epoch seconds and follows the same convention as list_clips, and that the memo field carries AI recognition results—these are useful behavioral details beyond the schema.

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

  Conciseness4/5

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

  The description is three sentences: the first states the core purpose, the second adds valuable context about the memo field, and the third clarifies the date format. Each sentence earns its place, though the second is a bit verbose.

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

  Completeness4/5

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

  For a simple 2-parameter tool with an output schema present, the description covers the essential aspects: purpose, ordering, date semantics, and memo field. It does not explicitly explain the 'limit' parameter, but the schema default and output schema partially mitigate that gap.

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

  Parameters2/5

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

  The schema has 0% description coverage, so the description must compensate, but it does not. It only implies the 'camera' parameter through the phrase 'for a camera,' and the 'limit' parameter is not mentioned at all, leaving the agent to guess its meaning despite the default of 20.

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

  Purpose5/5

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

  The description opens with 'List motion/AI alerts for a camera, newest first,' which clearly states the verb (List), the resource (motion/AI alerts), and a key behavior (newest first). It also positions the tool as the 'fast path' for identity questions, effectively distinguishing it from siblings like list_clips.

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

  Usage Guidelines4/5

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

  The description explicitly says this is the 'fast path for who/what triggered this camera and when,' providing clear when-to-use context. It also notes that it can answer identity questions 'without a separate face-recognition lookup,' suggesting an alternative approach, though it does not explicitly contrast with sibling list_clips.

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

• list_camerasA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains important nuances, such as the difference between is_no_signal and is_online, which prevents misinterpretation of camera health. It also specifies that is_no_signal indicates a specific grey placeholder image, adding useful behavioral context beyond a simple field list.

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

  Conciseness5/5

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

  The description is exactly two sentences with no filler. The first sentence states the purpose, and the second provides detailed field semantics. Every sentence adds value, and the structure is clear and front-loaded.

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

  Completeness4/5

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

  Given the simplicity of the tool (no parameters) and the presence of an output schema, the description covers the essential meaning of key fields. It explains the critical distinction between is_online and is_no_signal, which is likely not obvious from schema alone. It could mention whether the list is sorted or if any filtering options exist, but these are not necessary for a basic list operation.

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

  Parameters4/5

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

  The tool accepts no parameters, and the input schema is empty, so there are no parameter semantics to describe. The baseline for zero-parameter tools is 4, and the description does not need to compensate for undocumented parameters. It instead focuses on output meaning, which is appropriate.

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

  Purpose5/5

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

  The description opens with a clear, specific action: 'List configured Blue Iris cameras with live health status.' This uses a concrete verb and resource, and the additional field definitions further clarify what the tool returns. It is distinct from sibling tools like get_snapshot and list_alerts, so there is no ambiguity.

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

  Usage Guidelines3/5

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

  The description implies the tool is used when you need to enumerate cameras and their health, but it does not explicitly state when to use this tool over siblings or when not to use it. For example, it doesn't mention that get_snapshot is for images or list_alerts for events, leaving usage context implicit rather than explicit.

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

• list_clipsA
  4.3/5.0
  Behavior5/5

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

  With no annotations, the description carries full behavioral disclosure. It reveals ordering ('newest first'), scope ('full retention window'), limitations ('no separate date-range filter'), and how data fields (date, msec) relate to get_snapshot. This goes well beyond a basic read-only hint.

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

  Conciseness5/5

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

  The description is two tight paragraphs: the first sentence states purpose clearly, and the second adds valuable context about retention and usage. Every sentence contributes new information without redundancy.

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

  Completeness4/5

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

  The description is robust for behavior and integration, covering retention, ordering, and linkage to get_snapshot. The output schema covers return values, so no need to explain those. However, the missing parameter semantics for limit and the implicit handling of camera make it slightly incomplete overall.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for parameter meanings. It only implicitly references the camera parameter via 'for a camera' and completely omits the limit parameter. This is a significant gap given the description is the sole source of semantics.

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

  Purpose5/5

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

  The description opens with a clear, specific verb and resource: 'List recorded video segments for a camera, newest first.' This distinguishes it from sibling tools like list_cameras and list_alerts by focusing on video segments and their ordering.

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

  Usage Guidelines4/5

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

  The description provides clear context on when to use this tool: it covers the full retention window and lacks a date-range filter, implying it's for retrieving all available segments. It also mentions integration with get_snapshot, but does not explicitly exclude alternative tools or state when-not-to-use.

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

• get_snapshotA
  4.8/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of disclosing behavior. It clearly explains that the tool returns a JPEG frame, distinguishes live vs historical behavior based on pos_ms, and warns about the epoch unit mismatch. It does not mention error cases or authentication, but the key behavioral trait (what happens with and without pos_ms) is well covered.

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

  Conciseness5/5

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

  The description is two short paragraphs, front-loaded with the core purpose. Every sentence adds value: the first sentences states what it does, the second explains the optional parameter's behavior and how to source timestamps. No fluff or repetition.

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

  Completeness5/5

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

  For a tool with two parameters, no output schema, and no annotations, the description provides a complete contract: what it returns (JPEG frame), how to get live vs historical frames, and how to find suitable timestamps via sibling tools. It also warns about the unit mismatch. There is no missing information critical to invoking the tool correctly.

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

  Parameters5/5

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

  Schema coverage is 0%, so the description must explain all parameters, and it does. pos_ms is thoroughly explained: omit for live, pass Unix epoch milliseconds for historical, and specifically notes the multiplication from seconds. camera is somewhat self-explanatory but the description could benefit from referencing list_cameras; however, the primary parameter is handled with exceptional clarity.

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

  Purpose5/5

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

  The description opens with a specific verb+resource phrase: "Fetch a JPEG frame from a camera." It clearly distinguishes this from sibling tools (list_cameras, list_clips, list_alerts, ptz) by focusing on fetching a frame, not listing or controlling. The live vs historical distinction further clarifies the tool's unique purpose.

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

  Usage Guidelines5/5

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

  Explicitly states usage for both live and historical frames: "Omit pos_ms for the current live frame" and "Pass pos_ms ... to pull a historical frame instead." It also directs the user to list_clips or list_alerts to find timestamps, and provides a critical unit conversion tip (epoch seconds to milliseconds). This gives clear when-to-use and how-to-use guidance.

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

• ptzA
  5/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden, and it delivers rich behavioral disclosure. It specifies action semantics (momentary move, held for duration_s, capped at 3.0), requires preset for goto_preset (0-99), and explicitly warns about erratic movement caused by simultaneous PTZ sources. This goes far beyond a simple 'moves a camera' and covers side effects and limitations.

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

  Conciseness5/5

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

  The description is compact yet information-dense: a clear purpose sentence, a structured list of actions with constraints, and a final caution paragraph. Every sentence adds operational value or a critical caveat, and code-formatting for parameters improves scannability.

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

  Completeness5/5

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

  Despite lacking an output schema, the description covers all necessary operational knowledge: valid actions, parameter constraints, prerequisite hardware checks, and environmental caveats about competing PTZ pipelines. An agent can safely decide when to invoke and how to construct arguments.

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

  Parameters5/5

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

  The schema has zero description coverage, so the description must compensate. It does thoroughly: 'action' values are enumerated with meanings, 'duration_s' is explained as seconds with a 3.0 cap, 'preset' is described as required for goto_preset with a 0-99 range, and 'camera' is implied to be a PTZ-capable camera. This fully compensates for the bare schema.

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

  Purpose5/5

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

  The opening sentence clearly states the tool's function: 'Pan/tilt/zoom a PTZ-capable camera, or jump to a saved preset.' It names the resource (PTZ-capable camera) and specific verb actions, and the subsequent list of actions (left, right, up, down, home, zoom, stop, goto_preset) distinguishes it from sibling read-only tools like list_cameras and get_snapshot.

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

  Usage Guidelines5/5

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

  The description explicitly instructs users to verify PTZ capability via list_cameras' ptz_capable field before using, which is a clear when-to-use precondition. It also warns against sending competing PTZ commands when an automated pipeline is active, effectively stating when not to use the tool. This is exceptional guidance beyond a generic 'use to control camera.'

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