Frigate MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation3/5
Many tools relate to events and reviews with overlapping concepts, such as get_event_summary and explore_events both summarizing detections, or mark_reviewed and unmark_review_viewed dealing with review status. Descriptions help clarify differences, but the sheer number of similar operations makes misselection possible.
Naming Consistency4/5
Tool names consistently follow a snake_case verb_noun pattern (get_, set_, delete_, create_, mark_, etc.), making the set predictable. A few awkward names like unmark_review_viewed and reprocess_event_license_plate stand out, but they do not break the overall convention.
Tool Count1/5
With 59 tools, the server is far beyond the 'heavy' range and falls into the extreme category for tool count. While Frigate is a complex system, this many tools creates a steep learning curve and makes the set unwieldy for agents.
Completeness4/5
The toolset provides comprehensive coverage for the Frigate domain: event lifecycle (create, retrieve, update, delete, annotate), recordings, exports, reviews, faces, system config, stats, and logs. Minor gaps like direct camera CRUD and face image upload exist, but they can be worked around via config or external UI.
Average 3.7/5 across 48 of 59 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavior. It only states that it retrieves a summary, implying a read operation, but does not mention any potential side effects, data ranges beyond the parameters, or ordering/pagination behavior. The description is too thin to fully understand what the tool does beyond the literal meaning.
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 a single, front-loaded sentence with no wasted words. It delivers the core purpose efficiently and is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 optional parameters and an output schema, but the description does not explain what a 'timeline summary' actually contains or how the hourly buckets are constructed. It lacks enough context for an agent to understand the semantics of the result, especially given many similar sibling tools. The existence of an output schema partially compensates, but the conceptual description is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to restate parameter details. The phrase 'hourly bucketed' adds context that after/before define the time window for bucketing, but it does not clarify how the timezone parameter affects the buckets or how labels/cameras filter the summary. This is adequate but not enriched beyond baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('hourly bucketed timeline summary'), clearly indicating the tool returns timeline data aggregated by hour. It distinguishes itself from the sibling tool 'get_timeline' by explicitly mentioning the hourly bucketing, providing useful differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as 'get_timeline' or 'get_event_summary'. The context is implied by the name and description, but there is no explicit mention of preferred scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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. However, it gives no behavioral details beyond the basic action, such as read-only nature, return format, or potential edge cases. It's too sparse to be informative.
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 one concise sentence that efficiently conveys the core functionality without any wasted words. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with good schema coverage and an output schema, so the description doesn't need to explain return values. However, it lacks usage guidance and alternative recommendations, making it less complete for optimal tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter split_joined is fully described in the input schema (100% coverage), so the description doesn't need to add much. The description's example adds minimal context but doesn't enhance the schema's explanation, meriting a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all sub-labels with an example (identified person names), making the purpose explicit. It distinguishes itself from the sibling get_labels by using the term 'sub-labels,' though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like get_labels or set_event_sub_label. The description only states what it does, without any context for when it should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only states the core toggle behavior (reviewed/unreviewed) but does not mention side effects, permanence, permissions, or return behavior. This is insufficient for a mutation tool with zero annotation support.
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 a single concise sentence that effectively conveys the tool's purpose without wasted words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema covers parameters, but the description omits important contextual details such as behavior on invalid IDs, atomicity for multiple IDs, or any side effects. It is minimally viable but leaves gaps that an agent might need clarified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented in the schema (e.g., 'reviewed' default true, 'review_ids' list). The description adds no extra meaning beyond what the schema provides, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Mark review items as reviewed') and the resource ('review items'), and also notes it can set unreviewed. However, it does not differentiate from the similar sibling 'unmark_review_viewed', so it lacks explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'unmark_review_viewed' or 'delete_reviews'. There are no prerequisites, exclusions, or contextual hints beyond the basic action, leaving the agent to infer usage from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether deletion is permanent, reversible, or requires special permissions, nor does it mention any side effects or constraints.
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 a single, concise sentence that immediately states the action and object. There is no redundancy or filler; it earns its place perfectly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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, the description is minimal but lacks crucial context such as whether deletion is permanent, any behavioral caveats, or differentiation from other delete tools. With no annotations and a sparse description, it falls short of completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the 'export_id' parameter with 100% coverage. The description adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a video export' uses a specific verb and resource, clearly distinguishing it from sibling tools like delete_event and delete_reviews. It is unambiguous about 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, when to avoid using it, or contrast with other delete operations such as delete_event.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without explaining consequences, reversibility, permission requirements, or side effects on event state or retention. This is insufficient for a mutation tool.
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 a single sentence, front-loaded with the action and object, and contains no redundant words. It is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description lacks usage guidance and behavioral context. For a mutation tool with no annotations, this leaves significant gaps about the effect and proper usage, making the context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter with a clear description 'Event ID to mark as false positive', achieving 100% schema coverage. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'mark' and resource 'event' with the state 'false positive detection', clearly indicating the tool's function. It distinguishes from sibling tools like retain_event or delete_event by stating the specific action of marking as false positive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any conditions, prerequisites, or exclude any use cases, leaving the agent to infer when marking an event as false positive is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool does ('reprocess') and the intended outcome ('update predictions'), but does not disclose side effects, whether it modifies or deletes the image, whether it triggers recomputation of embeddings, or any permissions required.
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 a single, concise sentence that front-loads the primary action and result. There is no redundant wording or filler, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple one-parameter tool with an output schema, the description lacks critical context for a state-changing operation. It does not explain what 'reprocess' entails, whether it is destructive or reversible, how long it takes, or what the response contains. This is inadequate for an agent that needs to invoke it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a 100% coverage description for the single parameter (training_file), so the baseline is 3. The tool description adds 'to update predictions' which gives context for why the parameter matters, but does not add new semantic detail beyond the 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 description clearly identifies the action ('Reprocess'), the resource ('a face training image'), and the purpose ('to update predictions'). This is specific and distinguishes it from sibling tools like reprocess_event_license_plate (which targets license plates) and rename_face (which renames).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as after adding new face images or when predictions are stale. It does not mention prerequisites (e.g., having a training image in the faces/train directory) or conditions that warrant reprocessing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It only states 'set' without explaining side effects (e.g., does it replace existing attributes?), validation rules, or error handling. This is a significant gap for a mutation tool.
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 a single sentence that immediately conveys the tool's purpose. It is front-loaded and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks essential behavioral context for a mutation tool: whether attributes are additive or overwriting, what constitutes a valid attribute name, and any preconditions. This incomplete semantics could lead to incorrect invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes both parameters clearly. The description adds no additional semantic meaning beyond what's in the input schema, so it stays at the baseline score of 3.
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 clearly states the action (Set), the target (an event), and the specific resource (custom classification attributes). This distinguishes it from sibling setters like set_event_sub_label and set_event_description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. With many sibling set_* tools, this missing instruction makes selection ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear the full disclosure burden. It only mentions that associated media is deleted, but omits critical details like irreversibility, required permissions, or impact on related data such as exports or recordings.
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?
Extremely concise and front-loaded: one sentence that states the verb and resource immediately. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple one-parameter delete tool, and an output schema exists to cover return values. However, it lacks details about the consequences of deleting associated media, potential constraints, or interactions with other features.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the only parameter (event_id), so baseline is 3. The description adds no extra meaning beyond the schema, merely restating that the event is specific.
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?
Clearly states the action (delete), the resource (a specific event), and a key side effect (associated media). It distinguishes from sibling tools like delete_export and delete_reviews by targeting events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as end_event or retain_event. It provides no context about prerequisites or situations where deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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. It merely says 'Get details for a specific export,' which essentially restates the tool name. It does not disclose that this is a read-only operation, whether it returns null/404 for missing IDs, or any permission/authentication requirements. This is minimal behavioral disclosure.
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?
One short sentence with no filler, front-loaded with the action and resource. It is concise and appropriately sized for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter getter with an output schema, the description is adequate but leaves gaps. It does not explain where to obtain export_id or how this relates to get_exports, but the output schema handles return structure. It is a minimal viable description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with the parameter export_id described as 'Export ID.' The tool description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details for a specific export' clearly identifies the action (get), resource (export), and specificity (one export). It is not a tautology and distinguishes itself from get_exports, though it does not explicitly mention the export_id parameter or compare with the plural variant.
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 usage: use when you need details for one specific export. However, it provides no explicit when-to-use guidance or alternatives, such as using get_exports to list all exports or delete_export to remove one. The sibling tool names offer context, but the description itself does not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It only states the lookup action without mentioning side effects, error behavior, or return format. The output schema may cover returns, but the description adds no meaningful behavioral context beyond the tool name.
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?
A single sentence, front-loaded with the action ('Find') and the resource ('review segment... associated with a given event'). Zero wasted words, perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter lookup tool with an output schema, the description is adequate but minimal. It lacks any context about when to use this over sibling review tools and does not clarify what a 'review segment' is. Given the large number of related tools, a bit more contextual guidance would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter event_id is fully described in the schema with 'Event ID', giving 100% schema coverage. The description does not add any additional meaning beyond what the schema already provides, so the baseline score of 3 applies.
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 uses the specific verb 'Find' and clearly identifies the resource 'review segment' associated with 'a given event'. This distinguishes it from sibling tools like get_review_by_id, which operate by review ID rather than event ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or alternative guidance is provided. The intended usage is implied by the description (use when you have an event_id), but there are no explicit exclusions or comparisons with sibling tools such as get_review, get_reviews_by_ids, or get_review_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It does add useful context by explaining that the timeline shows chronological progression of detection events (e.g., object entered zone, attribute changes). However, it does not explicitly state read-only behavior, permissions, or output format, though the latter is covered by the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences with the action front-loaded. It provides a brief, relevant explanation of the timeline content without any unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives the core purpose and what the timeline contains, and the output schema covers return values. However, given the large sibling list, it lacks context on how this tool relates to other event/timeline tools and does not clarify differences from get_timeline_hourly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter (limit, camera, source_id) having a descriptive comment. The tool description adds no additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the detection timeline' with a specific verb and resource, and explains the timeline's content. However, it does not explicitly distinguish this from sibling tools like get_timeline_hourly or other event access tools, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_events, search_events, or get_timeline_hourly. It only describes what the tool does, with no context on selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the action without mentioning side effects, required permissions, or what happens if the export does not exist. It does not disclose whether the rename replaces the old name or if any validation occurs.
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 a single short sentence with no redundant words, making it highly concise and front-loaded. Every word contributes to stating the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with a complete schema and an output schema, the description conveys the essential action. However, it lacks usage guidelines and behavioral transparency, which are important for an AI agent to correctly select and invoke it, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both 'name' and 'export_id' (100% coverage), so the baseline is 3. The description adds no additional parameter meaning beyond what the schema already states.
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 uses the specific verb 'Rename' and the resource 'video export', clearly distinguishing this from sibling tools like create_export, delete_export, or get_export. The purpose is immediately understandable without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites such as the export existing or being in a modifiable state. It is a bare action statement with no context about the appropriate scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description provides no behavioral details such as side effects, error conditions, or whether renaming affects existing references. For a mutation tool, this is insufficient.
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 a single, concise sentence that front-loads the key information without any filler. Every word contributes to clarity, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and full schema coverage, the description is minimally adequate, but it lacks behavioral transparency and usage guidance that would make it fully complete for an AI agent. Output schema exists, so return values are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (old_name, new_name) are fully described in the schema (100% coverage), and the description adds no additional semantic information beyond what the schema already provides, so baseline 3 applies.
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 uses a specific verb ('rename') and resource ('registered face'), making the tool's function immediately clear and distinct from siblings like reprocess_face or delete_face_images.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool, prerequisites, or alternatives. It only states the action without any context on choosing it over other face-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It does not mention that setting a description will overwrite any existing description, nor does it address permissions, side effects, or idempotency.
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 a single clear sentence that is appropriately sized and front-loaded. Every word earns its place with no unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/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, full schema coverage, and presence of an output schema, the description is minimally sufficient. However, it lacks any context about when to use it or what happens on set, which is a gap in a crowded tool set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters, so the description adds no additional semantic value beyond the action. Baseline of 3 is appropriate given the schema handles parameter meaning.
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 uses a specific verb 'Set' with a clear resource ('text description on an event'), clearly distinguishing it from sibling tools like set_event_sub_label or set_event_attributes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool compared to alternatives such as regenerate_event_description or set_event_attributes. It simply states the action without any contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the key detail that the output is a base64-encoded JPEG, which is useful. However, with no annotations, the description carries the full burden and does not mention any potential errors, permissions, size implications, or side effects. Since this is a simple 'get' operation, the lack of mutation cues is implied, but not fully transparent.
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 a single, front-loaded sentence that directly states the action and result format. No filler or redundant information, every word is necessary.
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 retrieval tool with fully described schemas and an output schema present, the description is nearly complete. It lacks only usage context to differentiate from sibling tools, which prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters (event_id, crop, quality), so the description adds no additional parameter semantics beyond the schema. The baseline of 3 applies because the description does not compensate with extra details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Get the snapshot image for an event') and the result format ('base64-encoded JPEG'). However, it does not explicitly distinguish this from sibling tools like get_event_thumbnail, whose purpose is likely similar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_event_thumbnail or get_event. There is no mention of appropriate scenarios, exclusions, or prerequisites, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only mentions the output format ('base64-encoded JPEG') and implies readability via the verb 'get', but does not disclose potential errors, permissions, side effects, or any constraints. This is minimal for a tool with no structured safety hints.
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 a single, precise sentence that conveys all necessary information without redundancy. It is appropriately sized for the tool's simplicity.
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 tool is simple (one required parameter), has complete schema coverage, and an output schema exists, so return values are presumably documented there. The description covers the essential purpose and output format, making it adequate for the given complexity. It could mention potential errors or required permissions, but overall it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the single parameter event_id with a description ('Event ID'), and coverage is 100%. The description adds no additional meaning or context for the parameter, so the baseline score of 3 applies.
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 clearly states a specific action ('Get') on a specific resource ('thumbnail image for an event') and specifies the output format ('base64-encoded JPEG'). This distinguishes it from sibling tools like get_event_snapshot or get_latest_frame.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description only states what it does, leaving the agent to infer usage from the tool's name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses the basic scope ('all recognized license plates') but omits details like deduplication, ordering, handling of deleted events, or the effect of the split_joined parameter on results.
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 a single, clear sentence with no unnecessary words. It front-loads the action and resource efficiently.
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 tool is simple, has an output schema, and one optional parameter with a complete schema description. The description adequately covers the core purpose and return scope; while it could mention edge cases or volume implications, the provided context is sufficient for a basic list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter split_joined, fully explaining its behavior. The description adds no additional parameter semantics beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List all') and resource ('recognized license plates that have appeared in events'), making its purpose unmistakable and distinguishing it from siblings like get_events or get_labels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_events or get_labels. The description only states what it does, not in which scenarios it should be preferred or avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains what review items are and that alert severity is higher priority than detection, adding some behavioral context. However, it does not disclose default time boundaries, pagination, sorting behavior, or explicitly state read-only semantics beyond the verb 'Get'.
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 sentences long, front-loaded with the core purpose ('Get review items from the Frigate review queue'), followed by concise domain context. Every sentence adds value with no redundancy or padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers basic purpose and domain context, and the output schema handles return values. However, given the many review-related sibling tools and 8 optional parameters, it does not provide guidance on when to use this listing tool over others or mention its filtering capabilities beyond severity. The agent must rely on the schema for full usage details.
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?
All 8 parameters are already documented in the schema, giving a baseline of 3. The description enriches the severity parameter by defining alert vs detection priority, which is meaningful information not present in the schema. This addition justifies a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves review items from the Frigate review queue, using a specific verb ('Get') and resource ('review items'). It adds useful domain context about what review items are and severity priority. However, it does not explicitly distinguish this from sibling tools like get_review_by_id or get_reviews_by_ids, though 'from the Frigate review queue' implies a general listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It mentions severity priority but does not advise on choosing get_review over get_review_by_id, get_review_summary, or other review-related tools. No context is given for filtering or common use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavioral traits. It does reveal that recordings are deleted in addition to review items, which is a meaningful side effect. However, it does not mention permanence, permissions, or other potential impacts, leaving gaps in transparency.
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 a single, succinct sentence that communicates the core action and a critical side effect without unnecessary detail. It is front-loaded and every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no nested objects) and an output schema exists, so the description does not need to explain return values. However, it lacks usage context and fails to clarify the scope or consequences beyond the brief mention of recordings, making it sufficient but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a full description for the only parameter (review_ids). The tool description adds no additional meaning beyond what the schema states, so the baseline score of 3 applies.
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 clearly states the action ('Delete') and the target resource ('review items'), and adds a key distinguishing detail ('and their associated recordings'). This differentiates it from sibling tools like delete_event and delete_export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as mark_reviewed or delete_event. The description does not mention exclusions, prerequisites, or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It adds context that events are AI-detected objects and that filters can narrow results, which is useful. Yet it does not disclose key behaviors such as the default limit of 20, ordering of results, or explicitly state that this is a read-only operation. No contradiction with annotations exists.
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 sentences, front-loaded with the core purpose, and contains no redundant information. It efficiently communicates the tool's main function and provides useful context about event semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values do not need explanation. The description covers basic functionality and filter possibilities, but it lacks context for choosing among the many sibling event-related tools and omits important default behaviors like the 20-event limit. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does provide a brief summary of filter categories (camera, label, zone, time range) but does not add meaning beyond the individual parameter descriptions already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists detected events from Frigate with optional filters. It uses a specific verb ('List') plus a resource, and the meaning is unambiguous. However, it does not explicitly distinguish itself from sibling tools like get_event_summary or search_events, so it falls 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions using filters to narrow results by camera, label, zone, or time range, which gives some context about when to use the tool. However, it does not provide explicit guidance on when to prefer this tool over alternatives, nor does it mention exclusions or scenarios where other sibling tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states a bulk fetch, which is inherently read-only, but provides no details on error behavior, pagination, or relationship to other tools. This is a minimal disclosure.
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 a single sentence with no filler, front-loading the verb and resource. It is concise and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter bulk fetch with an output schema, the description is adequate but lacks explicit guidance on when to prefer it over get_event and what happens for missing IDs. It covers the basic purpose but not the full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents event_ids with a clear description, and the tool description adds no additional semantics. Since schema coverage is 100%, the baseline of 3 applies.
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 clearly states the tool fetches events by IDs, using a specific verb 'bulk fetch' that distinguishes it from the singular get_event and the broad get_events. It is concise yet precise.
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 usage when the user has multiple event IDs to fetch at once, but it does not explicitly contrast with calling get_event repeatedly or mention any alternatives. This is implied rather than explicit, so a 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only restates the function's basic action without adding context such as read-only nature, meaning of 'recent', pagination/limits, authentication needs, or error behavior. This is a significant gap given the absence of annotation support.
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 a single concise sentence with no fluff, front-loaded with the verb and resource. It is appropriately sized for a simple tool, though it could have added a bit more context without becoming 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 tool with one optional, fully-documented parameter and an existing output schema, the description covers most needed context. The main omission is defining 'recent' (e.g., lines or time window) and clarifying that the tool returns logs from any of the listed services rather than only 'frigate'. Nevertheless, the schema fills in service details, and the output schema handles return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the only parameter, 'service', including allowed values and a default. The description adds no extra semantic meaning beyond the schema, so it meets the baseline for high coverage but does not exceed it.
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 clearly states the verb 'Get' with a specific resource ('recent log output') and scope ('from a Frigate service'). This distinguishes it from all sibling tools, none of which focus on logs, so the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: it retrieves recent logs from a service. However, there is no explicit guidance on when to use this tool versus alternatives, no exclusions, and no reference to related log or diagnostic tools. The intended use case (e.g., debugging) is not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry the full burden. It states the basic function but doesn't disclose behavioral traits such as response format, error conditions, or how 'gaps' are computed relative to parameters. The verb 'Get' implies a read-only operation, but without annotations, this is not explicitly conveyed.
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?
A single sentence states exactly what the tool does with no wasted words. The parenthetical adds a helpful synonym for 'unavailable periods' without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple read tool with a rich output schema, but it doesn't explain what 'gaps' means in relation to the parameters (e.g., how scale affects granularity, whether gaps are per camera or across all). Since the schema and output schema cover the mechanical details, a terse description is acceptable, though it falls short of being fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema documentation covers 100% of the parameters with meaningful descriptions, including defaults and formats. The description adds no additional parameter context, but the schema already provides sufficient meaning, so a baseline of 3 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 uses a specific verb 'Get' and a clear resource 'time ranges where no recordings are available', which distinguishes it from sibling tools like get_recordings or get_recording_summary. The parenthetical '(gaps)' immediately clarifies the core concept.
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 clearly implies when to use this tool—when gaps in recordings are needed—but it doesn't explicitly state alternatives or when not to use it. Compared to siblings that retrieve recordings or summaries, this tool is unique in focusing on unavailable periods, but no direct comparison or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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. 'Fetch' implies a read operation, but there is no disclosure of error behavior, authentication needs, or what distinguishes a 'segment' from a regular review. The description essentially restates the tool name without adding meaningful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that is front-loaded with the action and resource. No unnecessary words or repetition, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple signature and presence of an output schema, the description is minimally adequate. However, it does not distinguish this tool from closely named siblings like get_review or get_reviews_by_ids, leaving potential ambiguity about when to use this specific fetch-by-ID variant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the sole parameter (review_id) with a description ('Review segment ID'), providing 100% coverage. The tool description adds no additional meaning beyond this, so the baseline score of 3 applies.
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 clearly states the action ('Fetch') and the specific resource ('a single review segment by its ID'), making it distinct from sibling tools like get_reviews_by_ids and get_review_by_event. The verb+resource structure is specific and unambiguous.
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 usage when a review segment ID is available, but it does not explicitly state when to choose this tool over alternatives like get_review or get_review_by_event, nor does it offer exclusions. Guidance is purely implied by the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only says 'Bulk fetch', which implies read-only, but it does not mention rate limits, partial failure behavior, authentication requirements, or how invalid IDs are handled. This is a significant gap for a tool operating over a batch of IDs.
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 a single, front-loaded sentence with zero filler. Every word earns its place, providing the essential scope in a compact form. It is appropriately concise for a tool with one parameter and no complex qualifiers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema, so the description need not detail return values. However, the absence of behavioral notes (e.g., error handling, limits) and explicit usage guidance means the description is only minimally viable, relying on the name and schema for full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description already covers the only parameter (review_ids) with 100% coverage, so the baseline is 3. The description's 'by ID' aligns with the parameter but does not add additional meaning beyond what the schema provides, such as constraints on array size or ordering.
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 uses a specific verb 'Bulk fetch' with a clear resource ('review segments') and scope ('by ID'), making it easy to distinguish from siblings like get_review_by_id and get_review_by_event. The name itself reinforces the plural nature, leaving no ambiguity about 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'Bulk' implies the tool is designed for fetching multiple review segments by ID, but there is no explicit guidance on when to use it versus single-ID alternatives or any exclusions. The description does not reference sibling tools or highlight scenarios where this tool is preferred, leaving usage to be inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Ask... to regenerate' without revealing whether the existing description is overwritten, whether it can fail (e.g., if GenAI is disabled), or if there are latency/cost implications. The 'force' parameter in the schema hints at some behavior, but the description itself is silent.
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 a single sentence, front-loaded with the action and resource, and contains no redundant or unnecessary words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema and output schema cover parameter details and return values, so the description does not need to repeat them. However, the lack of usage guidelines and behavioral transparency leaves noticeable context gaps, making it minimally adequate but incomplete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all parameters, so the baseline is 3. The description adds no additional parameter meaning beyond noting the GenAI provider, which is only loosely related to the 'source' parameter and not explicitly explained.
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 clearly states the tool's action: 'Ask Frigate's GenAI provider to regenerate the event description.' This specifies the verb (regenerate), resource (event description), and mechanism (GenAI provider), distinguishing it from siblings like set_event_description (manual setting) and get_event (retrieval).
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 usage when an AI-generated description is desired, but it offers no explicit guidance on when to choose this over alternatives like set_event_description, nor any prerequisites or conditions (e.g., GenAI being enabled). This is merely implied usage rather than explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only states 'Set' without disclosing side effects, whether it overwrites existing sub-labels, error behavior, or authorization requirements. This is a minimal disclosure for a mutation tool.
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 a single, front-loaded sentence with no wasted words. Every part earns its place, providing the primary purpose and an illustrative example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, schema covers all parameters, and an output schema exists, so the description need not explain return values. However, it lacks guidance on when to use vs. sibling tools and doesn't hint at expected behavior beyond the action itself, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds only a parenthetical example for sub_label, while sub_label_score is already well described in the schema. No significant added meaning.
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 clearly states the verb 'Set' and the resource 'sub-label on an event', with an example that distinguishes it from other event-setting tools. It is specific and immediately understandable.
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 gives an example of when to use it ('to identify a specific person') but does not explicitly mention alternatives or exclusions. However, the name and example imply it is for sub-labels as opposed to other setters like attributes or description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions user-scoping ('for the current user') but omits potential edge cases, reversibility, or prerequisites. The description adds minimal context beyond the core action, which is a gap given the lack of annotation support.
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 a single, concise, front-loaded sentence with no filler words. Every word contributes to the meaning, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and has an output schema, so return values are covered structurally. However, the description lacks explicit context on when to use this tool relative to the closely related 'mark_reviewed', leaving the agent to infer the intended use case. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the single parameter 'review_id' with a description that matches the tool's description. The description adds no new semantic information beyond the schema, so the baseline score of 3 applies per the rubric.
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 clearly states the action ('Mark a single review item as not-viewed') with a specific verb and resource, and explicitly scopes it to 'the current user'. This distinguishes it from the sibling tool 'mark_reviewed', which performs the opposite action.
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 usage for reversing viewed status, but it does not explicitly state when to use this tool versus alternatives like 'mark_reviewed'. No exclusions or explicit alternative guidance is provided, leaving usage to be inferred from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden of conveying behavioral traits. The verb 'Get' implies a read-only operation, which provides some transparency. However, it does not mention potential errors (e.g., event not found), authentication requirements, or response format specifics beyond what the output schema already defines. It is minimally adequate for a simple getter.
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 a single, clear sentence with no wasted words. It is front-loaded and immediately communicates the tool's purpose. It earns a perfect score for conciseness and structure.
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 tool is simple (one parameter, output schema exists), and the description clearly indicates the action and scope ('full details' vs. summary). While it does not explicitly discuss alternatives, the phrase 'full details' provides enough context for selection among siblings. Combined with the output schema, the description is mostly complete for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes 'event_id' as 'The event ID to retrieve' (100% coverage). The description adds no additional meaning beyond that, merely restating 'by its ID'. With complete schema coverage, the baseline of 3 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 'Get full details for a specific event by its ID' uses a specific verb ('Get') and resource ('event'), and the phrase 'full details' distinguishes it from the sibling tool 'get_event_summary' which likely returns a summary. This clearly states 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'get_event_summary', 'get_events', or 'get_events_by_ids'. There is no mention of prerequisites or appropriate contexts, leaving the agent to infer usage solely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'End' implies a mutation, but it does not disclose side effects such as whether the event is finalized, if recordings are affected, or if special permissions are required. This is a significant gap for a state-changing operation.
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?
A single, direct sentence with no redundant words. It front-loads the core action and condition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, and the description covers the core operation. However, it lacks behavioral post-conditions or error context, and given no annotations, it does not fully inform the agent of consequences. The output schema exists, so return values need not be described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes event_id with its purpose ('Event ID to end'), and the tool description adds no further semantic detail. With 100% schema coverage, the baseline of 3 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 uses a specific verb ('end') and resource ('in-progress event manually created'), clearly distinguishing it from delete_event and other event operations. It precisely states the scope of the tool.
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?
It provides clear context on when to use the tool: only for manually created, in-progress events. It does not explicitly mention alternatives or when-not-to-use scenarios, but the conditional framing guides selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'Get', implying a read-only operation, but does not disclose return structure beyond what the output schema already provides, nor any limitations or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states exactly what the tool does. There is no redundant information or filler.
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?
Given the tool has no parameters and an output schema exists to document return values, the description is complete for a simple, read-only schema retrieval 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 has zero parameters, so the baseline score of 4 applies. The description does not need to explain parameters that do not exist.
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 clearly states the tool retrieves the JSON Schema for Frigate's configuration, using a specific verb and resource. It naturally distinguishes from siblings like get_config (which likely retrieves the actual config) and save_config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that get_config is for the actual configuration, nor does it describe any context for schema inspection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly indicates a read operation ('Get'), but does not disclose how data is aggregated, whether both motion and audio are returned together, default time ranges when params are omitted, or any rate limits. It adds scope context but lacks deeper behavioral detail.
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 a single, clear sentence that front-loads the core purpose. Every word contributes value, and there is no unnecessary detail or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema and parameter descriptions exist, the description does not clarify crucial usage context: all parameters are optional, yet the description implies a time range is needed. It also does not mention how 'scale' affects output or how 'cameras' should be specified, though the schema covers some of this. The tool is simple, but the description leaves ambiguity about default behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with each parameter individually described. The description adds a high-level summary ('across cameras and a time range') but no additional meaning beyond what the schema already provides. Baseline 3 is appropriate given full schema coverage.
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 uses a specific verb ('Get') and clearly identifies the resource ('motion + audio activity data') with scope ('across cameras and a time range'). It distinguishes this tool from siblings like get_timeline or get_stats, which are not specifically for motion/audio activity.
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 usage for retrieving motion/audio activity data, but it does not provide explicit guidance on when to use this tool versus alternatives. No exclusions or alternative tools are mentioned, so the agent must infer usage from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral details. It only states the action without addressing side effects, idempotency, permissions, or whether the operation overwrites existing results. This is a significant gap for a processing/mutation tool.
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 a single, short, front-loaded sentence with no filler. Every word contributes to the core meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and an output schema, allowing a lean description. However, as a reprocessing action, it omits behavioral context such as whether it is synchronous, whether it modifies event state, or whether the event must exist. These gaps prevent a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with event_id described as 'Event ID to re-run LPR on'. The description adds no additional parameter semantics beyond the schema, so the baseline 3 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 uses a specific verb 'Re-run' and clearly identifies the resource: license plate recognition on an event's snapshot. It is distinct from sibling tools like reprocess_face by specifying 'license plate' and 'event's snapshot'.
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 implies the use case: when an event's snapshot requires LPR reprocessing. It provides clear context but does not explicitly mention alternatives or exclusions, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It states the action ('manually create') and the purpose, but omits any side effects, permission requirements, reversibility, or what happens to the created event (e.g., whether it triggers recording or is stored indefinitely). The description does not go beyond a high-level mutation statement, leaving significant behavioral unknowns.
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 concise sentences, front-loaded with the core action and purpose. Every sentence earns its place, and there is no wasted wording. It is highly concise while still conveying the tool's primary use case.
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 simple create operation and the presence of an output schema, the description is reasonably complete. It explains the manual override context and the main use case. However, in the context of many sibling event-related tools, it could have clarified how this event differs from those created by detection or how it relates to tools like end_event or retain_event. Minor gap, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the 6 parameters with descriptions, so the schema already provides detailed parameter semantics. The description adds no parameter-specific information, but the baseline of 3 is appropriate since the schema does the heavy lifting. The description's phrase 'marking a time period' loosely relates to duration but doesn't add concrete 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 clearly states the verb and resource: 'Manually create an event on a camera.' It distinguishes the tool from siblings by emphasizing 'manually' and the use case of marking a time period as notable even without automatic detection. This makes the purpose unambiguous and distinct from event retrieval/deletion tools.
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 a clear context for use: 'Useful for marking a time period as notable even if Frigate didn't detect anything automatically.' This indicates when to use the tool, though it doesn't explicitly mention when not to use it or name alternatives. The guidance is adequate for a create operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses an authentication requirement (API key) but does not explicitly confirm read-only status, output format, or potential side effects. The term 'List' implies a read-only operation, but an explicit statement would improve transparency.
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 extremely concise, consisting of two short sentences. The first sentence states the core purpose, and the second provides a necessary prerequisite. No fluff or redundant information, making every word earn its place.
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 list tool with one optional parameter and an output schema, the description is sufficiently complete. It covers purpose and a key prerequisite. It could briefly mention what 'available' means or expected output, but the output schema handles return format, so this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single optional parameter with a description and default value (100% coverage). The description adds no parameter-specific details beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb 'List' and resource 'available Frigate+ models'. It does not explicitly differentiate from sibling tools, but the unique name and lack of similar sibling tools make its purpose unmistakable.
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 for when to use (listing Frigate+ models) and a prerequisite ('Requires a configured Frigate+ API key'). It does not mention exclusions or alternatives, but the usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'List recording segments' and does not disclose whether the operation is read-only, how results are ordered or paginated, potential limits, or any response format details. Basic additional context is missing.
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 a single concise sentence that front-loads the action and object. Every word contributes, with no filler or 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 tool is simple, has a well-defined schema with all parameters described, and an output schema exists. The description covers the essential purpose and scope. However, given the large number of recording-related sibling tools, a brief mention of how this differs from others would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal semantic value beyond the schema, only reinforcing the time-range concept already covered by the 'after' and 'before' parameter descriptions.
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 uses a specific verb 'List' and identifies the resource 'recording segments for a camera in a time range,' which clearly differentiates it from sibling tools like get_recording_summary (summary) and get_recordings_unavailable (unavailable).
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 phrase 'for a camera in a time range' provides clear context for when to use this tool, but it does not explicitly mention alternatives or exclusions among the many sibling tools. There is no 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the return format ('recording hours grouped by day') but does not mention side effects, safety, or timezone-dependent grouping behavior.
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?
Two sentences, front-loaded with the primary action, and the second sentence adds valuable context about return value and use case without repetition.
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 output schema exists, the description sufficiently covers purpose and context. It could mention timezone implications, but the schema handles parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents both parameters. The description adds minimal parameter context ('for a camera') and does not address the timezone parameter beyond the 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 description uses a specific verb ('Get') and resource ('summary of recordings for a camera'), and clarifies the output as recording hours grouped by day. This clearly distinguishes it from sibling tools like get_recordings or get_recording_storage.
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?
It states a use case ('useful for understanding how much footage is available') but does not explicitly contrast with sibling tools or provide when-not-to-use guidance. Usage is implied rather than explicitly directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does disclose that the output is grouped by severity and day and covers a 24-hour period, which is useful. However, it does not mention whether this is a read-only operation, how the optional filters (zones, labels, cameras) interact, or any limitations such as timezone handling. The existence of an output schema partially compensates for the lack of return format details.
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 a single, concise sentence that front-loads the key action and result: 'Get a 24-hour summary...'. It contains no fluff or redundant information, every word earns its place, and it is easy to parse at a glance.
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 that the tool has four optional parameters, a fully self-describing schema, and an output schema, the description is reasonably complete for a simple summary operation. It covers the core behavior (24-hour window, grouping by severity/day) without needing to explain return values. However, it does not clarify subtle points like the exact meaning of '24-hour' (rolling vs day) or how filters affect the summary, leaving minor gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with all four parameters (zones, labels, cameras, timezone) having descriptions like 'Comma-separated zones' and 'IANA timezone'. The description adds no additional parameter semantics, such as how filters combine (AND vs OR) or the impact of timezone on the 'day' grouping. Since schema coverage is high, the baseline of 3 is appropriate, but no extra value is added by the description.
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 clearly states the tool's function: getting a 24-hour summary of the review queue, grouped by severity and day. This distinguishes it from sibling tools like get_review (which fetches individual reviews) and get_review_by_id (which fetches a specific review), as well as summarize_reviews. The verb 'get' and specific resource 'review queue' make the purpose unambiguous.
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 usage for obtaining an aggregated overview of the review queue over a day, but it does not explicitly state when to use this tool versus alternatives such as summarize_reviews or get_review. There is no mention of when not to use it or any prerequisites. The context suggests a summary tool, but without explicit guidance, it remains at an implied level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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. It discloses that the tool returns historical samples of CPU/memory/FPS, implying read-only access, but does not detail return format, ordering, pagination, or any side effects. This is minimal but not misleading.
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 a single sentence, front-loaded with the main action, and contains no filler. Every word contributes meaning, making it highly concise and well-structured.
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?
This is a simple getter tool with one optional parameter and an output schema, so the description plus schema cover the essentials. It could benefit from an explicit pointer to 'get_stats' for current data, but overall it is adequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the sole parameter 'keys' with a clear description ('Comma-separated stat keys to filter (omit for all)'), giving 100% schema coverage. The tool description adds no extra parameter information, so baseline 3 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?
Description clearly states 'Get historical stats samples' with the specific resource being 'recent CPU/memory/FPS history', using a specific verb and scope. It distinguishes from the sibling 'get_stats' by explicitly using 'historical', making the tool's purpose unambiguous.
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 historical framing implies this tool complements 'get_stats' (likely current stats), but no explicit guidance is given about when to use this tool versus alternatives. The use case is implied but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the action of setting/correcting, without mentioning permissions, whether the operation is destructive/reversible, or any side effects. This is a minimal level of transparency.
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?
One concise sentence that directly states the tool's purpose with no wasted words.
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 tool is a simple setter with three parameters, all documented in the schema, and output schema present. The description combined with schema gives a clear picture, though it could benefit from a hint about when manual correction is appropriate relative to automatic reprocessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with informative parameter descriptions such as 'empty string clears it' for plate. The description adds no additional parameter semantics, so baseline 3 applies.
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 uses a specific verb 'set/correct' and clearly identifies the resource 'recognized license plate on an event'. It distinguishes from sibling tools like reprocess_event_license_plate by emphasizing manual action.
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 word 'Manually' implies use cases where automatic processing is not desired, providing clear context. However, it does not explicitly name alternative tools or state 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly states the core behavior (creating a new export) and the input scope. However, it does not disclose potential side effects, whether the operation is asynchronous, permission requirements, or the fact that 'source' can be 'preview' rather than only recorded footage.
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 sentences, front-loaded with the primary action, and contains no filler. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters and no annotations, but an output schema exists. The description covers the main purpose and required parameters, yet it omits context around optional parameters like source and playback, and does not explain how the export process behaves (e.g., whether it's immediate or queued). This is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all six parameters. The description adds value by framing start/end as defining a section of recorded video and specifying the camera, but it does not explain the optional parameters (name, source, playback) beyond what the schema already provides.
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 uses a clear verb ('Create') and resource ('video export'), and specifies the scope: 'a section of recorded video between the start and end timestamps for the specified camera.' This distinguishes it from sibling tools like delete_export, rename_export, and get_export.
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 implies when to use this tool (when you need a video export from recorded footage) and provides clear context around timestamps and camera. However, it does not explicitly state when not to use it or mention alternatives such as preview source or other export-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It states that it 'Returns disk usage information', implying a read-only operation, but lacks details about aggregation, units, or whether it modifies anything. The behavior is minimally transparent.
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 two short sentences and fairly efficient. The second sentence repeats 'recording storage' and adds little value, but overall it is concise and front-loaded with the main purpose.
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 zero-parameter read-only getter, the description is adequate. It names the resource and return type, and an output schema exists to provide detailed return structure. However, it does not clarify whether 'across all cameras' implies an aggregate or per-camera breakdown.
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 has zero parameters with an empty input schema, so parameter semantics are trivial. The description correctly avoids mentioning any parameters, which is appropriate given the 100% schema coverage and absence of parameters.
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 uses the specific verb 'Get' and identifies the resource as 'recording storage usage across all cameras', making the scope clear and distinguishing it from sibling tools like get_recordings or get_stats.
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?
No explicit guidance is provided on when to use this tool versus alternatives like get_stats or get_recording_summary. Usage is implied by the tool name and description, but no exclusions or alternative mentions are included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It does list the output contents, which gives some transparency, but it does not explicitly state that the operation is read-only, non-destructive, or mention any prerequisites or side effects. This leaves the safety profile ambiguous, though the 'Get' verb implies a safe read.
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 sentences, front-loaded with the core purpose, and the second sentence efficiently enumerates the included metrics. There is no wasted wording or irrelevant detail.
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 zero-parameter tool with an output schema, the description is sufficiently complete. It states the purpose and details the return content, leaving no major gaps for an agent to select and invoke the tool correctly.
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 has zero parameters, so the schema already covers everything. The description adds no parameter details, which is acceptable; the baseline for 0-parameter tools is 4, and the description does not harm that.
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 uses a specific verb ('Get') and resource ('Frigate system statistics'), and enumerates the exact data returned (CPU/memory, detector speed, camera FPS, per-process consumption). This clearly distinguishes it from sibling tools focused on events, recordings, or configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, such as the sibling 'get_stats_history' for historical stats. The description simply states what it does without any context on use cases or exclusions, providing no comparative usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool returns 'the most recent items per label across all cameras' and groups results by label, which describes the output behavior. However, it does not mention any side effects, limitations, or additional behavioral traits beyond the summary nature. For a no-param read-only tool, this is adequate but not rich.
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 sentences, immediately states the core function, and provides a use case without excessive detail. It is well-structured 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 tool's simplicity (no parameters, output schema provided), the description covers the essential purpose and return structure. It explains grouping and recency, and adds a practical use case. It lacks any caveats or limits, but the presence of output schema reduces the need for such detail. Overall, it is complete for a tool of this complexity.
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 has zero parameters, and the schema reflects that with 100% coverage. The description adds no parameter info, but with no parameters, the baseline for this dimension is 4. No extra semantics are needed.
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 uses a specific verb 'Get' and identifies the resource 'events' with a clear scope: 'recent events grouped by label' and 'across all cameras.' This distinguishes it from siblings like get_events or get_event_summary by emphasizing the grouped summary nature and the 'what's been happening?' default view.
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 suggests a use case ('useful as a default "what's been happening?" view') but does not explicitly compare to alternatives or state when not to use it. It provides implied context but lacks explicit exclusions or sibling differentiation for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It explains the internal 'rolling best snapshot per (camera, label)' behavior, which adds useful context, but it does not clarify edge cases like missing snapshots, what 'best' means, or the exact return representation.
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 sentences: the first states the exact operation, and the second adds meaningful context about the rolling snapshot and a realistic use case. No words are wasted.
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 lookup tool with an output schema and full parameter schema coverage, the description is largely complete. It could mention what happens when no snapshot exists, but the core purpose and behavior are sufficiently conveyed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with camera, label, and height all described in the input schema. The description adds no semantic detail beyond the schema, so the baseline of 3 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 'Get the most recent best thumbnail for a camera + label combo,' which clearly states the verb, resource, and scope. It distinguishes this from sibling event-specific tools like get_event_thumbnail by emphasizing the camera+label rolling snapshot concept.
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 gives a concrete use case: 'a quick "what's the latest person seen on the front door?" query.' This provides clear context for when to use the tool, though it does not explicitly name alternative tools or state 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It describes grouping behavior but does not disclose details like read-only nature, potential time-range scope, or side effects. Since it's a read operation, the lack of side-effect disclosure is acceptable, but additional context would improve it.
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 sentences, front-loaded with the core function. Every sentence adds value: the first states what it does, the second suggests a use case. No fluff.
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 tool has one optional parameter, an output schema, and a simple read operation. The description covers the function and use case sufficiently for basic selection. It could mention the default timezone behavior, but the schema provides the parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single optional parameter (timezone) with its description, so schema coverage is 100%. The description does not add parameter-specific semantics beyond the schema, which is acceptable.
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 clearly states the tool returns a summary of events grouped by label, camera, and day, using a specific verb and resource. It distinguishes from sibling event tools like get_event (single event) and get_events (list), though it does not explicitly differentiate from summary tools like get_recording_summary.
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?
It provides a clear use case—understanding detection patterns over time—which implies when to use it. However, it does not explicitly state when not to use it or mention alternative tools, so no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the scope ('all object labels') and filtering behavior, but does not mention any edge cases, ordering, historical depth, or read-only confirmation beyond what the verb 'get' implies. This is adequate for a simple READ operation but does not go beyond the obvious.
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 three short sentences that front-load the core action and follow with optional filtering and examples. No filler or repetition—every sentence earns its place.
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 a single optional parameter, an output schema, and the straightforward nature of the tool, the description is complete. It states the default behavior (all labels) and the filter option without needing to explain return values since an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds the example common labels list, which is helpful context, but does not add material meaning to the 'camera' parameter beyond the schema's own description ('Camera name to filter labels for').
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 'Get all object labels that have been detected,' which clearly states a specific verb and resource. The optional camera filter further refines the scope, and this differentiates it from sibling tools like get_camera_label_best or get_sub_labels which target specific label types or best labels.
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 states the primary use case (retrieve all detected labels) and provides explicit optional filtering guidance ('filter to labels seen on a specific camera'). It does not mention alternatives or exclusions, but the context is clear for a simple lookup tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description needs to convey behavioral traits. It correctly discloses the primary effect (prevents auto-deletion) and implies a toggle, but it does not explicitly state that setting retain=false will un-retain, nor does it mention reversibility or permissions. The behavior is partially transparent but leaves room for clarification.
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 a single, compact sentence that directly states the purpose and effect with no unnecessary words. It is front-loaded with the primary action and immediately clear.
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 two-parameter tool with an output schema, the description provides sufficient context for basic usage. It lacks edge-case details such as behavior when the event is already retained or when an invalid event_id is provided, but these are likely covered by the output schema and are not critical for a straightforward toggle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters (event_id and retain). The description adds no additional parameter-level detail beyond what the schema already provides, matching the baseline for high schema coverage.
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 clearly states the action ('Mark an event as retained (favorited)') and the resource ('event'), with a specific consequence ('so it won't be auto-deleted'). This distinguishes it from sibling tools like delete_event or mark_event_false_positive by focusing on retention.
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 implies when to use the tool—when an event should be protected from automatic deletion—and provides clear context. It does not explicitly mention alternatives or when not to use it, but the purpose is straightforward enough to infer correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a significant behavioral trait: the requirement for Frigate+ or a configured search model. It also implies read-only search behavior. However, it doesn't disclose what happens if prerequisites are unmet, potential latency, or any error conditions.
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 three concise sentences. The first sentence states the core action, the second adds examples, and the third states a prerequisite. Every sentence earns its place with zero 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?
Given the tool has 8 parameters and an output schema, the description is reasonably complete. It explains the query parameter via examples and mentions a key prerequisite. It doesn't discuss other parameters, but those are well-covered in the schema. A slight gap is not explicitly differentiating from structured search tools like get_events, but the semantic-search framing largely suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 8 parameters, so the schema provides complete param semantics. The description adds marginal value by giving example query formats ('person at front door', 'red car') that clarify the 'query' parameter. No other params are discussed, but the baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs natural language/semantic search on events: 'Search events using natural language / semantic search.' It distinguishes from sibling tools by specifying the search mechanism and providing concrete example queries like 'delivery person' and 'dog in yard.'
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 indicates when to use the tool: 'Great for queries like...' giving natural language use cases. It also states a prerequisite ('Requires Frigate+ or a configured search model') which informs the user of conditions. However, it doesn't explicitly mention alternatives or when not to use it, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It discloses a key dependency (GenAI configuration) and indicates the operation is powered by an external provider, implying potential latency or cost. It does not detail side effects or rate limits, but for a read-only summarize action, the disclosure is adequate.
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 only two sentences—the first states the core action and scope, the second gives a critical prerequisite. Every word earns its place, with no redundancy or filler.
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, the description is fairly complete. It covers the time-range semantics and the GenAI requirement. It could explicitly state what the summary output is (though the output schema exists) or address scenarios where GenAI is not configured, but these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides clear descriptions for both parameters (start/end Unix timestamps). The description adds that they define a 'time range' for summarization, but this is a minor reinforcement rather than new information beyond the schema's 100% coverage.
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 clearly states the tool's action ('summarize review items'), resource ('review items in a time range'), and method ('Frigate's GenAI provider'). This distinguishes it from sibling tools like get_review_summary, which likely provides a count or statistical summary rather than an AI-generated narrative.
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?
It provides clear context for when to use the tool (to summarize reviews with GenAI) and explicitly states the prerequisite that GenAI must be configured. However, it does not explicitly mention when not to use this tool or name alternatives, such as get_review_summary or get_review, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only listing operation via the verb 'List', which conveys non-destructive behavior. However, it does not disclose pagination, authentication requirements, or limitations on the 'all' scope. With no annotations, the description carries the full burden but adds minimal behavioral context beyond the basic operation.
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?
A single, clear sentence with no filler. Every word earns its place.
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 simple list tool with no parameters and an output schema, the description is sufficient. It doesn't need to explain return values because the output schema covers that.
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 has zero parameters, and the schema is empty. According to the baseline for 0 params, this scores 4. The description adds no parameter information, but none is needed.
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 'List all video exports' clearly states the verb (List), resource (video exports), and scope (all). It distinguishes from sibling get_export, which presumably targets a single export.
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 usage for retrieving all exports, but does not explicitly contrast with get_export or any alternative. No when-not-to-use guidance is given, so it only partially addresses usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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. It discloses a prerequisite (face recognition must be enabled) and a limitation (multipart upload not exposed by this MCP server). But it does not mention behaviors such as idempotency (what happens if the folder already exists) or error conditions, leaving some gaps.
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 sentences with no fluff. It front-loads the purpose and then adds two concise, essential facts (prerequisite and post-creation workflow). Every sentence earns its place.
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 single-parameter create operation, the description covers the purpose, an important operational prerequisite, and the follow-up process for adding images. An output schema exists, so return values are not the description's responsibility. Minor omissions like error handling prevent a perfect score.
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?
Schema coverage is 100% for the single 'name' parameter, so baseline is 3. The description adds the constraint that the folder is for a 'new person' and explains the purpose of the folder (to hold training images added later), which provides useful semantic context beyond the 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 description clearly states the tool's action: 'Create a face folder for a new person.' This uses a specific verb and resource, and the context about enabling face recognition and uploading training images distinguishes it from sibling face tools such as rename_face and delete_face_images.
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 the tool: it requires Frigate face recognition to be enabled, and it clarifies that training images are uploaded separately via Frigate's UI, implying this tool does not handle that. However, it does not explicitly name alternatives or give a direct when-not-to-use statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on full responsibility for behavioral disclosure. It reveals a key behavioral consequence: deleting all images for a name effectively removes the person. This goes beyond the input schema and helps the agent understand the tool's impact. It does not mention reversibility or return values, but the core destructive behavior is clear.
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 concise sentences, front-loaded with the primary action. Every sentence earns its place: the first states what the tool does, the second explains a meaningful behavioral nuance. No filler or 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?
Given the tool's simple scope (two required parameters, no nested objects) and the presence of an output schema, the description sufficiently covers the core action and the important edge case of deleting all images. It does not explain error handling or return values, but the output schema likely covers that, and the description is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with clear descriptions for both 'name' and 'image_ids'. The tool description does not add parameter-specific detail beyond what the schema offers, so the baseline score of 3 is appropriate. The overall behavior context is helpful but not tied to individual parameters.
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 clearly states the action ('Delete'), the resource ('one or more stored face images'), and the target ('for a person'). The second sentence adds a crucial clarification about the effect of deleting all images, which distinguishes it from simply managing images and aligns with related face tools like rename_face and reprocess_face.
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 implicitly conveys when to use the tool—whenever you need to delete face images. It also provides a usage guideline by noting that deleting all images for a name effectively removes the person, suggesting an alternative approach to person removal. However, it does not explicitly name alternatives or state exclusions, which would push it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly states that the tool returns a base64-encoded string and is used to view current camera feed. This gives the agent a good sense of expected output and use, though it does not detail error conditions or latency behavior. Since this is a simple, non-destructive getter, the level of disclosure is adequate.
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 sentences long, front-loaded with the primary action, and contains no filler. It efficiently conveys the purpose, output format, and usage indication, making every sentence valuable.
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 tool's low complexity and 100% schema coverage, the description is fairly complete. It explains what the tool does, what it returns, and when to use it. An output schema exists (though not shown in the prompt), which reduces the need to describe return values. However, it lacks mention of potential error conditions or example invocations, which would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both 'camera' and 'height' are described in the input schema. The tool description adds no additional parameter semantics beyond what the schema already provides. The description does not compensate for any gaps because there are none, but it also does not enhance understanding of the parameters.
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 clearly states the tool's function: 'Get the latest camera frame as a JPEG image.' It specifies the verb (Get), the resource (latest camera frame), and output format. This distinguishes it from sibling tools like get_event_snapshot or get_event_thumbnail, which return event-related images rather than live camera frames.
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 a clear use case: 'Use this to see what a camera is currently viewing.' This indicates the appropriate context for the tool, but it does not explicitly mention alternatives or when not to use it. However, the context is sufficient for a straightforward read-only getter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It explicitly warns that 'This will briefly interrupt recording and detection,' which is a critical side effect. However, it doesn't mention other potential behaviors like termination of active streams or whether a config reload is included, so it is not fully exhaustive.
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 extremely concise: two sentences. The first sentence states the action, the second delivers a necessary warning. No filler or redundant information, making it highly efficient and well-structured.
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 tool with an output schema, the description covers the key contextual point—the interruption impact. It doesn't address prerequisites (e.g., must save config first) or alternatives, but given the simplicity and the existence of an output schema, it is sufficiently complete for an agent to invoke the tool correctly.
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 has zero parameters, so the description need not explain parameter meanings. Per the rubric, a baseline of 4 applies when there are no parameters, and nothing in the description contradicts or adds unnecessary parameter-related info.
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 clearly states the action ('Restart the Frigate process') with a specific verb and resource. It is unambiguous and distinguishes itself from sibling tools, as no other tool in the list performs a restart.
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 usage for restarting Frigate but does not explicitly state when to use it vs alternatives (e.g., save_config for config changes). The warning about interruption provides some context for deciding whether to proceed, but lacks explicit guidance on appropriate scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses that Frigate validates the YAML before persisting, which is a key behavioral trait, and also mentions the optional restart. It does not mention what happens on validation failure or the impact of a restart, but the disclosed info is meaningful and non-obvious.
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 sentences long, front-loading the primary purpose in the first sentence and adding critical constraints (admin, validation) in the second. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutation nature and absent annotations, the description adequately covers admin requirements and validation. An output schema exists, so return values are capturable. It lacks explicit warning about restart side effects, but the core context is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full coverage (100%) with descriptions for both parameters. The description lightly echoes this by referencing 'new Frigate YAML config' and 'optionally restart,' but adds no additional semantics beyond the schema, so a baseline score of 3 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 verb 'Save' clearly identifies the action, and the resource is specified as 'a new Frigate YAML config.' It also distinguishes from sibling tools like restart_frigate (which only restarts) and get_config (which reads).
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 states 'Admin only,' which is a usage constraint, and the optional restart behavior gives context on when to use it. However, it does not explicitly name alternatives or provide when-not-to-use guidance, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return format in detail (dictionary mapping person names to lists of filenames), which is a key behavioral trait. It implicitly indicates a read-only operation via 'Get', though it does not explicitly state there are no side effects or edge cases (e.g., empty dictionary when no faces are registered). For a simple getter, this is reasonably transparent.
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 sentences, front-loaded with the primary action and then a concise explanation of the return structure. Every sentence earns its place with no redundancy or unnecessary detail. It is appropriately sized for a zero-parameter tool.
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 simple getter with no parameters and an output schema present, the description is complete. It clearly defines the purpose and return format without requiring additional context. There are no complex edge cases or sibling interactions to explain, making the description sufficient.
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 has zero parameters, so the baseline score is 4. The description adds useful context about the output structure, which complements the empty input schema, though parameter-specific semantics are not needed since there are no parameters.
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 clearly states the verb 'Get' and the resource 'all registered face names and their image filenames', with an explicit scope (all) and the returned structure (dictionary mapping). It distinguishes itself from sibling tools like get_labels or get_recognized_license_plates by focusing on face names and filenames.
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?
Usage is implied by the description: use this tool when you need all registered face names and their associated image filenames. However, there is no explicit mention of when not to use it or alternative tools (e.g., if you need a single face or events, use get_event or get_labels). The lack of explicit alternatives keeps it at an implied level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the output is a version string, implying a read-only operation. While it does not mention potential failure conditions or side effects, the simplicity of the operation makes this sufficient for most use cases.
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 a single, front-loaded sentence with no redundant words. It efficiently communicates the tool's purpose without adding unnecessary details.
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 no parameters and simple output, the description adequately covers the essential information. The presence of an output schema means return value details are handled elsewhere, and the description aligns with the expected output.
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 has zero parameters, and schema coverage is complete (vacuously). The description adds no parameter details because none exist, which is appropriate. The baseline for 0-parameter tools is 4.
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 uses a specific verb ('Get') and resource ('Frigate server version'), clearly distinguishing it from sibling tools that retrieve events, recordings, or config. It unambiguously states 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool vs alternatives, but the purpose is so straightforward that usage is implied. Since no sibling tool serves the same function, the lack of explicit when/when-not statements is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It clearly indicates a read-only 'get' operation that returns the full configuration, which is sufficient for a simple getter. It does not mention authentication or performance, but these are not necessary given the tool's straightforward nature.
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?
Two concise sentences deliver the purpose and content without repetition. The first sentence states the action and resource; the second elaborates on what is included. No wasted words.
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?
The tool is simple (no params), has an output schema, and the description lists the main config components. Given the output schema covers return values, the description is complete enough for an agent to select and invoke the tool correctly.
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 has 0 parameters and an empty schema, so baseline is 4. The description adds no parameter details, but none are needed. It correctly focuses on the returned resource.
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?
Description clearly states the verb 'Get' and specific resource 'full Frigate configuration', listing contents (cameras, detectors, objects, recording, snapshots). This distinguishes it from siblings like get_config_schema (which returns the schema) and save_config (which writes).
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 implies when to use this tool: when you need the current running configuration. It contrasts with siblings by mentioning 'running config' but does not explicitly state exclusions or alternatives. Clear context but no explicit 'use this instead of...'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![frigate-mcp MCP server](https://glama.ai/mcp/servers/jakekeeys/frigate-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jakekeeys/frigate-mcp)

Score Badge

Copy to your README.md:

[![frigate-mcp MCP server](https://glama.ai/mcp/servers/jakekeeys/frigate-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jakekeeys/frigate-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jakekeeys/frigate-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server