Rhombus MCP Server
OfficialServer Quality Checklist
Latest release: v0.1.33
- Disambiguation4/5
Most tools have clearly distinct purposes, with detailed descriptions that differentiate similar ones like events-tool vs report-tool or multiple door-related tools. However, some potential overlap exists between camera-tool and update-tool for camera settings, and between get-entity-tool and entity-lookup-tool, but the descriptions mitigate confusion.
Naming Consistency4/5Tool names consistently use snake_case and follow a <domain>-tool pattern (e.g., access-control-tool, alarm-monitoring-tool). A few names like create-camera-policy-tool deviate slightly from the verb-noun pattern, but overall naming is predictable.
Tool Count3/5With 31 tools, the server is on the high side for a typical MCP server. While the domain (physical security) is broad enough to justify many tools, some tools could be consolidated (e.g., multiple door-related tools). The count feels slightly heavy but still manageable.
Completeness3/5The tool surface covers a wide range of operations across various domains (access control, cameras, analytics, LPR, etc.) but has notable gaps. Missing user creation, alarm management beyond monitoring, and full CRUD for locations (only create and update). Some operations require workarounds.
Average 4/5 across 31 of 31 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 79 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 failing
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.jsonto 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?
The description is inconsistent: it claims 'real-time snapshot' for 'image' but the timestampISO defaults to 5 minutes ago. There is no mention of destructive side effects, authentication needs, or rate limits. The behavior for two request types is completely omitted. Annotations are absent, so the description fails to provide sufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose, with redundant statements (e.g., multiple mentions of snapshot behavior). The structure is split by request type but includes a general 'Output filtering' section that could be better integrated. Some sentences are unnecessary, and the overall length could be reduced.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should explain return values for all request types. It partially does for 'image' (image and frameUri) and 'get-settings' (JSON object), but ignores 'get-media-uris' and 'get-ai-thresholds'. The filtering parameters are described, but the data structure for settings is not detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value to requestType (lists enum values), timestampISO (default and format), and the filtering parameters (includeFields, filterBy) with warnings about large responses. For cameraUuid, it relies on the schema's description. With 80% schema coverage, the description effectively supplements the remaining details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description lists four request types but only describes 'image' and 'get-settings' in detail. The general introduction ('perform some action pertaining to the video stream') is vague, and the usage example about selecting cameras based on features is mixed into the 'image' section, causing confusion. The other two request types remain undefined, reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
For 'image', an example scenario is provided (selecting cameras based on features). For 'get-settings', a clear note directs to use update-tool for changes. However, no guidance is given for 'get-media-uris' and 'get-ai-thresholds', and the overall context of when to use each request type is missing.
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 exist, so the description must fully disclose behavior. It mentions actions but fails to explain side effects, error handling, authentication needs, or conditional parameter usage clearly. The required parameters in schema conflict with conditional actual use, creating potential confusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured by action with hyphens. The opening sentence is slightly redundant but overall it is well-organized and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-action tool with 5 conditional parameters and no output schema, the description lacks critical details—such as mapping parameters to actions explicitly. It omits information about the locationUpdate parameter and fails to clarify that most parameters are only required for specific actions, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60%, with three parameters having descriptions. The description adds marginal value by noting name vs UUID preference, but does not clarify the locationUpdate object or action enum beyond what schema provides. It does not significantly enhance schema meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs operations on locations and lists four specific actions (get, create, update, get-labels). However, it lacks differentiation from sibling tools like camera-tool or door-tool, which might overlap conceptually.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage hints, such as using location names over UUIDs for reports, and notes requirements for update and create actions. However, it does not explicitly guide when to use this tool versus siblings, or 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 mentions the multi-step process and 'uses elicitation forms for rich user interaction,' hinting at interactive behavior. However, it does not disclose side effects (e.g., persistent resource creation), required permissions, or error states. The generic output filtering warnings are not behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose, with a large block of generic output filtering instructions that are not specific to this tool. The core purpose and steps are stated concisely, but the boilerplate text should be removed or placed elsewhere. This hurts readability and conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 required parameters, multi-step process, output schema exists), the description covers the workflow adequately but does not explain the return value, success indications, or error conditions. The output filtering section adds noise rather than completeness. The description is sufficient but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already describes all 9 parameters. The description adds some context by explaining the steps (e.g., first three parameters for creation, then scheduleConfigs, then cameraUuids). However, it does not add significant semantics beyond what the schema descriptions already provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: creating a camera policy via a multi-step process. It distinguishes from siblings like policy-alerts-tool by focusing on policy creation. However, the generic output filtering section slightly clutters the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description outlines the three steps (create, configure schedules, assign cameras), which helps the agent understand the workflow. However, it lacks explicit instructions on when to use this tool over alternatives or when not to use it. No sibling tool directly competes, so the guidance is adequate but not exemplary.
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 explains the four modes and warns about large responses, but omits behavioral traits like error handling, idempotency of creation operations, required permissions, or side effects. This is a partial disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for modes and output filtering. It is front-loaded with the core purpose. Minor redundancy (e.g., repeating 'Requires' in each bullet) could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the multi-mode complexity and presence of an output schema, the description covers the basics: modes, required params for each, and filtering. Missing context includes error conditions, dependency availability, and what the response contains for creation operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value by organizing parameters by requestType, explaining required dependencies, and providing examples for includeFields and filterBy. This goes beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages Rhombus door controller rules and door policies, and lists four specific operation modes with required parameters. However, it does not explicitly differentiate this tool from sibling tools like 'rules-tool' or 'access-control-tool', which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions using get-entity-tool to find UUIDs, but provides no guidance on when to use this tool versus other sibling tools (e.g., rules-tool for non-door rules). There is no 'when not to use' or alternative tool suggestions.
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?
The description does not disclose any behavioral traits beyond the basic function. There are no annotations, so the description carries full burden but fails to mention if it is read-only, if authentication is needed, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It is concise and well-structured, though brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is mostly complete. It lists key outputs but could mention behavior like caching or error handling. Still, it is adequate for a basic info getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so the schema coverage is 100%. The description adds value by listing the types of information returned, which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves organization information and lists examples (org name, camera config defaults, etc.). It is specific and uses a verb-resource pair, but does not distinguish from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of context, prerequisites, or when not to use it. Given many sibling tools, this is a gap.
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 provided, so description must disclose behavioral traits. Only states 'performs an action' and reconnection effect. Does not mention potential side effects like service interruption, permission requirements, or confirmation process.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is adequately concise but includes redundant phrases like 'this is a helpful option' and all-caps 'THIS TOOL PERFORMS AN ACTION'. Front-loaded with purpose, but could be more direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema, description lacks details on synchronous/asynchronous behavior, effect on ongoing operations, and purpose of confirmationId. Incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only cameraUuids has description). Description adds no parameter-specific information beyond the schema. The confirmationId parameter is left completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool reboots cameras and causes reconnection, distinctly different from sibling tools like 'camera-tool' or 'camera-uptime-tool'. Verb+resource is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions usage when camera has connectivity issues or needs troubleshooting, providing clear context. Does not explicitly compare to alternatives or state when not to use, but guidance is helpful.
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 warns about large responses (400k characters) and recommends includeFields and filterBy, which is helpful. However, it does not disclose mutation safety, permissions, or side effects of creating a video wall. With no annotations, more detail on behavioral traits is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes a lengthy generic section on output filtering that is likely repeated across tools. The purpose is front-loaded, but overall verbosity could be reduced. It is adequately structured but not concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description covers core aspects: purpose, parameter behavior (layout determination), and output size warnings. It adequately equips an agent to invoke the tool, though some edge cases (e.g., error handling) are omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining how 'numVisibleDevicesAtOnce' determines layout and providing extensive context on output filtering. This goes beyond the schema definitions, earning a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool interacts with Rhombus video walls and lists the supported actions (list, create) via requestType enum. It clearly identifies the resource and verbs, but does not explicitly differentiate from sibling tools like camera-tool or clips-tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 does it explain when to use list vs create beyond the schema. Prerequisites or context for using the tool are absent.
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 provided, so the description must disclose all behavioral traits. It reveals that the tool mutates settings and uses a multi-step process with current value display, but lacks information on error handling, idempotency, authorization needs, or potential side effects like camera reboots.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy and includes a mix of core functionality, specific instructions, and a generic output filtering section. It is front-loaded with the main purpose and structured with bullet points, but some parts like the future support list could be trimmed for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, a multi-step process, and faceted UUIDs, the description covers entity types, settings categories, process flow, and output filtering. It has an output schema so return values are covered. Missing details on error handling and validation slightly reduce completeness, but overall it is thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, giving a baseline of 3. The description adds significant value beyond the schema, especially for cameraDeviceSettings (exact LED field names, underscore note) and includeFields/filterBy (warning about large responses and usage examples). This enrichment justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool updates configuration settings for Rhombus entities, specifically cameras currently, and lists the supported settings. It differentiates from sibling tools by focusing on updates rather than other operations, but does not explicitly contrast with other update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides step-by-step guidance and specific instructions for LED control, and mentions the faceted UUID default. However, it does not specify when to use this tool versus alternatives, nor does it provide when-not-to-use guidance or prerequisites.
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 provided, so description carries full burden. It discloses that data is exact and includes a 'connected' boolean field. However, it does not mention potential side effects, access restrictions, or response size limits. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two paragraphs, front-loaded with the core action. The second paragraph elaborates on the primary use case. Concise overall; no unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the essential aspects: purpose, use case, return structure (JSON string with states), and key behavioral detail (connected field). Could clarify that all entity types are considered 'devices' for health checks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline is 3. The description adds minimal new meaning to parameters beyond the schema's own descriptions. It notes the tool can request multiple types at once, which is already implied by the array schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves entities/devices and specifies it is the primary tool for device health checks. It distinguishes from siblings by implication but does not explicitly differentiate from entity-lookup-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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'When asked about device health, offline devices, or connectivity issues, use this tool.' Does not mention when not to use or provide alternatives, but the context is clear.
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. The description focuses on retrieving clips but the input schema includes createClip and deleteClip requestTypes, which are not mentioned in the description text. This creates a mismatch; the agent might not know the tool can also create or delete clips. The description does not disclose any destructive behavior or mutations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed and structured with bullet points and sections, but it is quite lengthy. It front-loads the main purpose, but includes extensive output schema details that could be in the output schema itself. Some redundancy exists (e.g., warning about large responses appears in both description and parameter descriptions). Could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, output schema exists), the description is fairly complete regarding retrieval operations and output filtering. It mentions retention period and warns about large responses. However, it omits the create/delete capabilities, which are part of the tool's functionality, making it incomplete for a full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant meaning beyond the schema by explaining filter options, output structure, and output filtering (includeFields, filterBy). It provides context for requestType values and clarifies that timestamps are in ISO 8601 format with examples. This adds value beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves saved video clips from the Rhombus system, with specific verb and resource. It distinguishes itself from the events-tool by explicitly saying 'This tool is not for looking up the events that have occured.' It also lists multiple request types, making the purpose clear and differentiating from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use the tool (retrieving clips) and when not (events). It explains filter options and output filtering. However, it does not mention alternatives among siblings beyond events-tool, and does not give guidance on when to use different requestTypes like createClip or deleteClip.
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 provided, so description carries full burden. It describes a read-like operation but does not explicitly state it is safe or has side effects. For a simple query tool, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus an example, all highly relevant. No wasted words. The instructions are front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers what the tool does, when to use it, and how to set parameters. Lacks details on return format, but for a time tool that is often acceptable. Overall sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides 100% coverage for both parameters. The description adds valuable context by advising to keep time_description close to the user's query, which helps the agent formulate the parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns time from a natural language query, distinguishing it from sibling tools like time-conversion-tool. However, it could be slightly more explicit that it handles both current time queries and time descriptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on when to use (e.g., 'if user asks about current time') and how to construct the time_description parameter. Lacks explicit exclusion of alternatives, but the sibling list includes time-conversion-tool which implies different 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?
No annotations are provided, so the description must disclose behavioral traits. It states it returns a 'precise count' but does not specify whether duplicates are counted, how invalid UUIDs are handled, or if the operation has side effects. The description is basic and omits important details for full 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the purpose, and contains no unnecessary wording. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description adequately explains the input and return value. It could mention edge cases (empty array, invalid UUIDs), but is sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both the array and its items. The description adds no significant meaning beyond what the schema already provides, meeting the baseline for a well-documented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool counts items by accepting UUIDs. It specifies the verb 'count' and resource 'items by UUIDs', distinguishing it from siblings like search-tool which return data rather than counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent to use this tool when needing a count of UUID-identified items, but does not explicitly exclude alternatives or mention when not to use it. The context is clear but lacks explicit differentiation from siblings.
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 cover behavioral traits. It states auto-detection and conversion, which is constructive. However, it omits details like error handling, output format, or restrictions, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, concise and front-loaded with the core purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple conversion tool with one parameter and no output schema, the description adequately covers inputs, behavior, and usage. It lacks details on output format, but the context of bidirectional conversion implies the result will be the opposite format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters and includes a description. The tool description adds auto-detection context, but does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'convert' and the resources 'epoch and ISO 8601 timestamps', indicating bidirectional conversion with auto-detection. It distinguishes itself from sibling tools like 'time-tool' which may handle different time operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool: 'when you have one time format and need to convert to the other format'. It does not provide alternatives or exclusions, but the context is clear enough for a simple conversion tool.
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 fully carries the burden of behavioral disclosure. It warns about response sizes (400k+ characters), explains the O(N^2) growth for permission group access maps, and recommends field filtering. This is comprehensive for a user management tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured with sections and bullet points. It is front-loaded with the tool's purpose and then dives into details. Each sentence seems necessary, though some redundancy could be trimmed (e.g., repeating the warning about response size in includeFields description).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (four modes, output filtering, heavy payload warnings) and the existence of an output schema, the description is mostly complete. It covers all modes, filter parameters, and performance considerations. It does not mention error handling or rate limits, but those are beyond typical expectations for a tool description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema. For requestType, it explains each mode. For includeFields and filterBy, it provides examples and notes on performance. The schema coverage is 100% but the description enriches understanding, especially for the complex filtering and mode selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages Rhombus user operations with four specific modes. It mentions using UUIDs with access-control-tool, which helps differentiate, but does not explicitly contrast with other user-related sibling tools like user-audit-tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use each requestType and warns about heavy payloads for get-permission-groups. It also suggests using includeFields and filterBy to control output. However, it does not compare with sibling tools or specify when to use this tool versus alternatives like user-audit-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 carries the full burden. It discloses the behavior of each mode (e.g., unlock-door is a write operation, get-groups is read-only) and warns about large responses. However, it lacks details on side effects, error handling, or permission requirements, which is a moderate gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points for modes, making it easy to scan. It front-loads the purpose. While it is lengthy due to the number of modes, every section serves a purpose; minor redundancy in parameter explanations could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, 9 modes) and the existence of an output schema, the description covers modes, required parameters, output filtering, and related tools. It could be more complete by briefly noting what each mode returns, but the output schema reduces that need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds significant value by clarifying which parameters are required for each mode and providing examples for includeFields and filterBy. This goes beyond the schema's generic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool manages Rhombus access control operations and enumerates nine specific modes via requestType. It differentiates from sibling tools by explicitly directing users to get-entity-tool, user-tool, and location-tool for UUID lookups, and states that this is the correct tool for remote unlock permissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance for each mode, including required parameters. It names alternative tools for prerequisite lookups and includes a warning about large responses. However, it does not explicitly state when not to use this tool versus a sibling beyond those mentions, leaving some implicit inference.
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 thoroughly discloses the tool's behavior: computes statistics, requires timestamps, enumerates modes, and warns about large responses with advice on includeFields/filterBy. The only minor gap is not explicitly stating that it is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured into sections (summary, modes, timestamps, output filtering). It is slightly verbose due to repeated examples for filterBy/includeFields, but overall it is efficient and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, enums, large responses) and the presence of an output schema (not shown but declared), the description is largely complete. It covers all modes, parameter requirements, and output filtering. It does not detail the exact return fields, but that is acceptable since an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining how parameters relate to modes (cameraUuid required only for get-camera-uptime), specifying that startTimeSec and endTimeSec are UNIX timestamps, and reiterating the filterBy/includeFields usage with detailed examples and warnings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes camera uptime and reliability, computing uptime percentages, outage counts, and longest outage durations. It distinguishes two specific modes (single camera vs fleet), which helps the agent differentiate from sibling tools like 'camera-tool' or 'events-tool'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly defines when to use each mode (single camera vs fleet), but it lacks guidance on when to prefer this tool over similar tools (e.g., 'camera-tool' for broader camera data). No when-not-to-use or alternative recommendations are provided.
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?
Discloses that exceptions overwrite existing schedules temporarily, that expired exceptions are in the past, and that omitting intervals can generate full-day intervals. Since no annotations exist, the description adequately covers behavior without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a general overview, mode list, and output filtering section. While thorough, some repetition (e.g., definition of expired) lengthens it slightly without significant loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is highly complete given the tool's complexity. It explains the domain (schedule exceptions), all modes, parameter relationships, output filtering, and response size warnings. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All input parameters have schema descriptions (100% coverage). The description adds valuable context beyond the schema, such as automatic location resolution when missing and default interval generation. This goes above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages door schedule exceptions and enumerates all modes of operation with specific actions. It differentiates from siblings by focusing on temporary schedule overrides, but does not explicitly contrast with other tools like door-tool or access-control-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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance for each requestType, explains automatic location resolution, references get-entity-tool for UUID lookups, and notes mirroring web console behavior for expired exceptions. Lacks explicit when-not-to-use instructions.
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 provided, so description carries full burden. It discloses exactness ('Only devices with matching UUIDs will be returned') and large response warnings, but omits safety, idempotency, or permission details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs: first states purpose, second provides critical output filtering guidance. Front-loaded main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains return structure as JSON of device states. Output schema exists so full detail isn't needed. Covers essential usage aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline 3. Description adds extra value beyond schema by warning about 400k character responses and advising use of includeFields/filterBy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves entities by UUIDs and returns device information including licenses and features, distinguishing it from sibling tools like search-tool which do free-text search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context: 'Use this tool when the user asks for details on devices' states and details about their licenses and features.' Lacks explicit when-not-to-use but the context is clear.
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 behavioral disclosure. It mentions that create/update require JSON config and that responses can be large, but it does not specify side effects (e.g., whether updates are idempotent, if deletion is permanent), authentication requirements, or potential errors. More detail 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear list of modes followed by output filtering details. It front-loads the purpose and uses bullet-like formatting for readability. However, it could be slightly more concise by merging redundant warnings about response size.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 modes, 6 params) and the presence of an output schema, the description covers the essential operational modes and parameter roles. It lacks information about prerequisites (e.g., permissions) and error handling, but overall it provides sufficient context 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so parameters are already described. The description adds value by grouping parameters by mode (e.g., list requires no ruleUuid) and clarifying output filtering parameters' purpose. It also explains that ruleConfig is a JSON string for rule definition, beyond the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages Rhombus automation rules for triggering actions based on events. It lists specific modes (list, create, update, delete, get-records) and provides context that rules can trigger notifications, recordings, etc. This distinguishes it from sibling tools like camera-tool or events-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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains each mode of operation and when to use each one, including required parameters per mode. It also warns about large responses and recommends using includeFields and filterBy. However, it does not explicitly state when NOT to use this tool or compare it to alternatives.
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 cover behavioral traits. It discloses that responses can exceed 400k characters and suggests using includeFields/filterBy. It does not mention rate limits, authentication needs, or side effects, which is acceptable for a read-only search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with bullet points and clear sections. It is detailed but could be slightly more concise by reducing redundancy (e.g., repeating the warning about large responses). Overall, it is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 params, multiple modes, output schema exists), the description covers operation modes, parameter requirements, and output filtering. It does not explain the return structure, but the output schema handles that. It is mostly complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by specifying which parameters are required per requestType, and provides examples and warnings for includeFields and filterBy, which goes beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it performs visual and data searches across Rhombus camera footage and events, with four distinct modes of operation. This clearly identifies the tool's purpose and differentiates it from sibling tools like lpr-tool or camera-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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly outlines when to use each mode by specifying required parameters. It advises using get-entity-tool to obtain camera UUIDs and warns about large response sizes. However, it does not explicitly state when NOT to use this tool (e.g., for simpler lookups).
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 full burden. It details the five modes, explains output filtering (includeFields, filterBy), and warns about large responses exceeding 400k characters. However, it does not explicitly state whether the tool is read-only or has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points for modes and a separate section for output filtering. It is front-loaded with the purpose. Every sentence serves a purpose, though it is slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no annotations, output schema present), the description covers all necessary aspects: five modes, request objects, output filtering with examples, and a warning about large responses. It is comprehensive enough for an AI agent to understand how and when to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant value by explaining what each mode answers in plain language (e.g., 'How busy is each area vs normal?'), which goes beyond the schema's formal parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it generates composite operational analytics reports by combining multiple data sources, and lists five specific modes of operation with clear answers to business questions. This distinguishes it from simpler data retrieval tools like count-tool or events-tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description recommends using the tool for high-level business questions, but does not explicitly state when not to use it or suggest alternative tools. It provides context for usage but lacks exclusion criteria.
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 provided, so description carries full burden. It warns about potential large responses and partial matches. However, it claims '3 modes' while the schema includes 5 modes (missing search-license-plates and save-vehicle), which is a significant omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, bold text for sibling tool comparison, and bullet-like formatting for modes. It front-loads the purpose. However, it is somewhat lengthy and repeats mode names unnecessarily.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers most aspects but misses two schema modes (search-license-plates, save-vehicle). Also lacks explanation of the output schema (though output exists). The description is fragmented with mode details mixed with general notes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining which parameters are used for which modes and providing context like date range recommendation. It enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool interacts with the Rhombus LPR system for license plate events and registered plates. It explicitly distinguishes itself from the events-tool, making 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool vs. events-tool (camera), and mentions location-tool for pairing events with locations. Also gives a best practice for labels: first call get-vehicle-labels then get-vehicle-events.
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 must carry full burden. It explains modes, output filtering, and warns about large responses. But it doesn't disclose read-only nature, authentication needs, or error handling for missing users.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: first paragraph states purpose, second details modes, third covers output filtering. No fluff, every sentence adds value. Front-loaded with key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (8 params, modes, output filtering), the description covers all necessary parts: modes, parameter dependencies, default limit, output filtering syntax and warning. With output schema present, return value explanation is not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining how requestType determines mode, role of email vs userUuid, and output filtering with examples. This extra context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it traces physical access events for a specific user across all doors and access points, and gives example questions. It distinguishes from sibling tools like user-tool by indicating when to use user-tool for UUID lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains two modes of operation and when to use each, and recommends user-tool for UUID lookup. However, it doesn't explicitly exclude other tools (e.g., events-tool) or state when not to use this tool.
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?
Without annotations, the description covers behavior well: it describes two modes, the structure of returned audit events, and warns about large responses. It does not mention authentication or side effects, but these are not critical for this read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, front-loaded with the main purpose. It is slightly verbose but every sentence adds value, making it efficient for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema and schema coverage, the description is complete. It covers all parameters, provides usage context, and warns about large responses. It could mention the default maxResults explicitly, but overall it's sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the meaning of requestType and the relationship between userUuid/targetUuid and modes, and by detailing the filtering parameters with examples and warnings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it retrieves configuration audit trails for specific users or targets, distinguishing it from a general audit feed. It clearly lists two modes and their purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use each mode, prerequisites like using user-tool to find userUuid, and explains output filtering to manage large responses. It does not explicitly state when not to use the tool, but the context is sufficient.
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 full burden. It discloses that responses can exceed 400k characters and provides filtering mechanisms. It implies read-only operations (listing, retrieving logs) without stating destructive effects, which is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with modes enumerated in bullet points, but it is somewhat lengthy. Every sentence adds value, including the warnings about large responses. Could be slightly more concise, but structure is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (three modes, six parameters, output schema exists), the description covers all essential aspects: modes, required parameters, optional time filters, and output filtering. The warning about large responses is critical. Output schema existence reduces need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline 3. The description adds context about the three request types and explains the filterBy and includeFields parameters with examples and warnings, providing value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages Rhombus guest/visitor operations and lists three specific modes (get-all-guests, get-activity-logs, get-activities-for-location), each with a clear purpose. It distinguishes from sibling tools by the guest management focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each mode based on the requestType parameter and provides filtering guidance (includeFields, filterBy) to handle large responses. It doesn't explicitly state when not to use this tool vs alternatives, but the context is sufficient.
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 behavioral disclosure. It warns about large response sizes exceeding 400k characters and explains output filtering parameters to mitigate this. However, it does not explicitly state whether the tool is read-only or mention any other behavioral traits like authentication requirements or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for each mode and output filtering. It is concise, front-loading the core purpose and modes, and every sentence adds value (e.g., warnings about large responses). No unnecessary repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has an output schema, the description does not need to detail return values. It covers all parameters, modes, and provides important warnings about response size. It lacks information about error conditions or prerequisites (e.g., whether a location UUID is required for location-status), but overall it is sufficiently complete for a multi-mode retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 7 parameters, but the description adds significant value by explaining the modes of operation driven by requestType, detailing the output filtering parameters (includeFields and filterBy) with examples, and warning about large responses. This goes well beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves alarm monitoring status and threat case information, with specific modes (org-status, get-threat-cases, location-status) that differentiate the tool's capabilities. It uses specific verbs ('retrieves') and resources ('alarm monitoring status and threat case information'), making its purpose unambiguous and distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists the three modes of operation and explains when each should be used based on the requestType parameter. It provides context for each mode but does not explicitly advise when not to use this tool or suggest alternatives among sibling tools.
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 provided, so the description carries full burden. It discloses that deleting removes stored responses, timestamps are ISO 8601, and includes warnings about large responses with filtering options. It lacks details on rate limits or auth requirements, but overall is 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (overview, modes, notes, output filtering) and front-loaded with a summary. It is thorough but not overly verbose; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (15 parameters, conditional requirements, multiple modes), the description is highly complete. It explains each mode's parameters, pagination, output filtering, and edge cases. 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.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value beyond the schema: it explains conditional requirements (e.g., invokeAt must be 15+ minutes future), relationships between parameters (notifyUserUuids must be in permissionGroupUuid), and usage of pagination cursors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages automated prompts with explicit verbs like list, inspect, create, update, delete, page, share, verify. It distinguishes itself from sibling tools by focusing solely on automated prompts, with no overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed usage guidance for each mode, including required and optional parameters, pagination, and a note to use 'user-tool' for UUID lookup. It does not explicitly state when not to use this tool, but the alternative is clear given its unique functionality.
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 full burden. It explains automatic name resolution, filtering behavior, large response warnings, and the faceEventFilter scope. However, it does not explicitly state if the tool is read-only or mention any rate limits. Overall, it adds significant behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headings for each requestType and output filtering, but it is verbose and contains some repetition (e.g., location UUID advice appears twice). It could be more concise while retaining clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, multiple requestTypes, nested objects, and an output schema), the description is comprehensive. It covers all requestType behaviors, sibling tool relationships, parameter usage, and response size warnings. The presence of an output schema does not detract from the description's completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 71%, but the description adds substantial value: it explains automatic name resolution for faceNames, precedence of faceNameContains, default time range of 7 days, and the use of includeFields/filterBy to manage large responses. It also clarifies that searchFilter only applies to get-face-events. This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: interacting with the Rhombus face recognition system to retrieve face sightings and registered faces. It distinguishes itself from sibling tools like report-tool (for head count) and events-tool (for access control), and provides specific usage for each requestType.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool vs alternatives, e.g., 'If the user is asking about how many people were seen, use the report-tool' and 'When asked whether specific people were seen... also call events-tool'. It provides clear context and 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 provided, the description carries the full burden of behavioral disclosure. It details response enrichment (faceCountEnrichment), fallback behavior, auto-selection of API based on promptType, and output filtering warnings (responses may exceed 400k characters). However, it does not mention rate limits, permissions, or whether operations are read-only, though these are less critical for a report tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Scope, People/occupancy counting strategy, Summary and occupancy, Line crossing, Custom LLM events, Audit and diagnostics, Output filtering). It is front-loaded with the core purpose and key distinction. While comprehensive, some repetition (e.g., faceCountEnrichment mentioned multiple times) slightly reduces conciseness, but every section earns its place with actionable guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 sub-tools) and that an output schema exists, the description is remarkably complete. It covers all sub-tool use cases, provides lookup strategies for cameras and prompts, explains fallback behavior, and warns about large responses with output filtering options. It also instructs the agent on error handling (e.g., telling user when camera lacks occupancy). No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 93%, so baseline is 3. The description adds significant context beyond the schema: it explains when each requestType is appropriate, how parameters relate to sub-requests (e.g., 'Required for requestType ===...'), and provides usage warnings for includeFields and filterBy. This adds practical meaning that helps the agent construct correct requests.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns aggregated counts and time-series summaries. It explicitly contrasts with events-tool (raw event-level data), providing a specific verb and resource distinction. The scope is well-defined: high-level reports, analytics, trends over periods of a day or more.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use and when-not-to-use guidance, including a direct comparison with events-tool for raw data. It also gives step-by-step strategies for people counting (always call GET_OCCUPANCY_ENABLED_CAMERAS first), line crossing, and custom events, with fallback instructions and alternatives.
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?
Discloses behavioral traits like timezone handling for different modes, that camera mode returns all activity types, and that brivo access-control automatically fetches configuration. Warns about response size. No annotations are provided, so the description carries the full burden. Minor omissions like pagination or rate limits prevent a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear headers for each mode and a scope section. However, some repetition of start/end time descriptions across modes could be trimmed. Still efficient for a multi-mode tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects: scope, mode selection, parameter requirements, output descriptions, filtering options, and sibling tool comparisons. Despite complexity, no obvious gaps. Output schema exists to supplement return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage, but the description adds significant value: clarifies which parameters are required per mode, explains defaults (duration=3600, limit=1000), and describes output structure for brivo mode. This is above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns raw event-level data and distinguishes itself from siblings: report-tool for aggregates, lpr-tool for LPR workflows. Each eventType mode is explicitly described.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool vs alternatives (report-tool, lpr-tool) and within the tool, which eventType to choose. Includes warnings about large result sets and suggests narrow time ranges.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: alerts vs notifications, unhealthy-devices returns historical not live data, large response warning, pagination details for different query types. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very long and dense, covering many aspects but lacking conciseness. It repeats some schema info and could be more streamlined. However, it is well-structured with sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 params, multiple query types, pagination, output filtering), the description is highly complete. It covers pagination per query type, output filtering warnings, and sibling tool differentiation. It explicitly states it's not exhaustive, setting expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds meaning for queryType enum values, time format details, pagination cursors, and output filtering. It goes beyond schema by explaining when to use each pagination parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieves Rhombus policy alerts' and distinguishes them from notifications. It explains what triggers alerts and contrasts with get-entity-tool for live device status, effectively differentiating from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use this tool (for policy alerts) and when not to (for live device status, use get-entity-tool). It also explains pagination and output filtering, providing clear context for alternative usage.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/RhombusSystems/rhombus-node-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server