AroFlo MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools are clearly distinct by targeting specific AroFlo zones (e.g., assets, clients, tasks), with minimal overlap. However, some tools like aroflo_get_record and aroflo_query_zone could be confused with the many specific get_* tools, as they offer more general querying capabilities. The descriptions help differentiate them, but an agent might need to carefully choose between specialized and general tools.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with the prefix 'aroflo_' and clear verb_noun structures (e.g., get_assets, create_or_update_record, list_open_projects). There are no deviations in naming conventions, making the set predictable and easy to parse.
Tool Count2/5
With 51 tools, the count is excessive for typical MCP server scopes (usually 3-15 tools). While AroFlo is a complex system, many tools are repetitive get_* queries for different zones, which could have been consolidated into fewer, more generic tools. This large number may overwhelm agents and increase selection complexity.
Completeness3/5
The tool set provides extensive read coverage across AroFlo's zones and includes a create/update tool, but lacks dedicated update, delete, or other write operations for most resources. There are also specialized reporting tools, but core CRUD lifecycle coverage is incomplete, relying heavily on querying with only one general write tool.
Average 3.7/5 across 51 of 51 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations establish read-only/idempotent safety; the description adds value by disclosing the client-side filtering behavior, the join operation ('tasks joined with project + tasktotals'), and the grouping/calculation logic ('group tasks by project with total hours'). It also mentions auto-pagination with caps, though doesn't specify cap behavior or rate limiting implications. Could better explain performance characteristics given the client-side processing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences achieve brevity but sacrifice necessary documentation given the complexity (12 parameters, 0% schema coverage). The front-loading of core functionality is good, however the density leaves too many parameters undocumented. 'Uses client-side filtering by projectId' is slightly awkward phrasing given projectIds is required, not optional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (reducing description burden), the tool has significant complexity—joining multiple data sources, client-side filtering, pagination logic, and 12 undocumented parameters. The description omits: date filter semantics (which date field each filters), boolean flag purposes (hoursOnly, includeUnassigned), mode enum behaviors, and error conditions. Given zero schema descriptions, the description should comprehensively document parameter semantics but fails to.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage across 12 parameters, the description inadequately compensates. While it implicitly references projectIds and pagination controls ('caps'), critical parameters like 'sinceDateRequested' vs 'sinceCreatedUtc' (ambiguous naming), 'hoursOnly', 'includeUnassigned', and the 'mode' enum values lack any semantic explanation. The relationship between 'mode', 'verbose', and 'debug' flags is unexplained despite potential overlaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the core operation: fetching tasks joined with project/tasktotals data and grouping by project with aggregated hours. Uses specific verbs (fetch, group) and identifies the resource. However, it does not distinguish from sibling 'aroflo_report_open_projects_with_task_hours' which appears to have similar domain overlap, leaving ambiguity about which tool to use for reporting needs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions 'client-side filtering' which hints at implementation characteristics, but provides no explicit guidance on when to use this tool versus 'aroflo_get_tasks' or the reporting siblings. No prerequisites, error conditions, or 'when not to use' guidance is provided. The pagination mention is technical rather than prescriptive.
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?
Annotations already declare destructiveHint=true and openWorldHint=true. The description appropriately confirms the mutation nature ('Create or update') and adds implementation context ('using zone + postxml'), but omits critical behavioral details like idempotency, partial versus full updates, or failure modes given the complexity of XML-based writes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with zero redundancy; every word conveys essential information. However, breverity crosses into underspecification given the tool's complexity (destructive operation with nested object parameters).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Grossly inadequate for a destructive, multi-mode operation with 7 parameters and nested objects. Fails to explain the XML payload structure, the 'zone' concept, or the purpose of output-modifying flags (mode, verbose, debug, raw) despite zero schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage across 7 parameters. The description mentions only 'zone' and 'postxml' (2 of 7), leaving 'extra', 'mode', 'verbose', 'debug', and 'raw' completely undocumented. With zero schema coverage, the description fails to compensate for undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verbs (Create/update) and resource (record) and distinguishes from sibling tools which are exclusively read operations (get_, list_, report_). The 'using zone + postxml' fragment clarifies the technical mechanism, though 'record' remains somewhat generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use create versus update, prerequisites for operation, or when to prefer this over read-only alternatives. The description merely states functionality without contextual selection 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?
Annotations declare readOnly/idempotent safety; description adds 'incremental sync' context implying time-based filtering. However, it omits behavioral details like valid 'zoneName' values, pagination limits (max 500), or how 'mode'/'verbose' flags alter output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single 9-word sentence with no redundancy. However, extreme brevity is inappropriate for a 9-parameter tool with zero schema documentation; it under-delivers rather than being optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Inadequate for complexity: 9 undocumented parameters require examples (valid zones), format guidance (UTC timestamps), and pagination logic. Output schema exists but description doesn't reference return structure or how incremental cursors work.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (critical failure). Description fails to compensate: 'zoneName' valid values are unspecified, 'sinceUtc' format is undocumented, and boolean flags (verbose/debug/raw) lack behavioral explanation despite being central to the tool's operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Uses specific verb 'Query' and identifies the resource 'lastupdate zone' and use case 'incremental sync workflows,' distinguishing it from sibling full-fetch tools like 'aroflo_get_tasks'. Minor opacity around 'zone' jargon prevents a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage context ('incremental sync workflows') but provides no explicit guidance on when to use this versus 'aroflo_query_zone' or specific entity getters, and fails to note that all 9 parameters are optional (0 required).
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?
Annotations declare read-only and idempotent safety. Description adds valuable behavioral context about the pipe-delimited query syntax and mode options. However, it omits critical behavioral details about pagination controls (page vs autoPaginate vs maxResults) and how they interact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Information-dense and front-loaded with purpose. Each clause delivers specific syntax rules or configuration options without redundancy. Slightly dense readability but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 18 undocumented parameters and complex overlapping pagination controls, the description is insufficient. While it covers query construction adequately, the omission of pagination behavior (critical for a large dataset tool) and zero schema coverage leaves significant gaps despite the existence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage across 18 parameters, the description partially compensates by documenting where/order/join syntax, mode, compact, and select. However, it completely fails to explain the complex pagination system (page, pageSize, autoPaginate, maxPages, maxResults, maxItems, maxItemsTotal) or the validateWhere and extra parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action 'Query' and resource 'AroFlo Projects zone', distinguishing it from sibling tools like aroflo_get_tasks or aroflo_get_quotes. However, it fails to differentiate from aroflo_list_open_projects or aroflo_query_zone, leaving ambiguity about which projects tool to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides essential domain-specific syntax guidance for pipe-delimited WHERE clauses and JOIN areas, but lacks explicit when-to-use guidance versus alternatives like aroflo_list_open_projects. No guidance on pagination strategy despite 6 related parameters.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, confirming safe read behavior. The description adds value by specifying 'one specific' record (implying singleton return vs. list) and documenting the pipe-delimited clause format for extraWhere. However, it omits behavioral details for the mode enum and boolean flags (verbose/debug/raw), which overlap in naming and need clarification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences with no wasted words. The first establishes purpose and main parameters; the second provides essential syntax guidance for the complex extraWhere parameter. However, given the severe lack of schema documentation, the structure could have been improved by referencing the existence of output formatting options (mode/verbose/debug/raw).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters with 0% schema coverage and no inline documentation, the description is insufficiently complete. While it covers the primary retrieval path, it leaves half the parameters (mode, verbose, debug, raw) completely undocumented, leaving users to guess their purpose and interaction with the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full burden of parameter documentation. While it explains zone, idField/idValue, and extraWhere (with syntax), it completely omits the mode enum (data/verbose/debug/raw) and the boolean flags (verbose, debug, raw), leaving 4 of 8 parameters undocumented and unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the core action ('Fetch one specific AroFlo record') and identifies the required identifying parameters ('zone and ID field/value'). However, it fails to differentiate this generic record getter from the numerous specific entity getters (e.g., aroflo_get_tasks, aroflo_get_projects) available as siblings, leaving ambiguity about which to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides valuable syntax guidance for the extraWhere parameter with a concrete example ('and|archived|=|false'), helping users construct valid queries. However, it lacks explicit guidance on when to use this generic tool versus the many specific entity getters (aroflo_get_tasks, etc.) or the aroflo_create_or_update_record sibling.
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?
Annotations cover read-only/idempotent safety. Description adds GET method confirmation and query DSL syntax. However, doesn't explain pagination behavior (offset vs cursor), the relationship between 'mode' enum and separate boolean flags (verbose/debug/raw), or the implication of openWorldHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Information-dense with six focused sentences. Examples are concrete. Structure flows logically from purpose → syntax → options → documentation reference. Minor deduction for cramming multiple clause types into one sentence without visual separation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
References external documentation resource for field validation, which is helpful given 18 undocumented schema properties. Output schema existence excuses return value documentation. However, incomplete given complexity: pagination model unexplained, validation behavior (validateWhere) unclear, and maxItems vs maxResults distinction missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description compensates well for complex parameters (where/order/join syntax, mode options, compact/select usage). However, completely omits explanation of six pagination-related parameters (page, maxPages, etc.) and the 'extra' object, which are critical for a query tool with 5K result limits.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action 'Query' and resource 'DocumentsAndPhotos zone' clearly. However, lacks distinction from generic query tools (e.g., aroflo_query_zone) present in siblings, and doesn't clarify if this returns metadata, file content, or both.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides excellent syntax examples for WHERE/ORDER/JOIN clauses, but fails to specify when to use this specific endpoint versus the generic 'aroflo_query_zone' or 'aroflo_get_record' siblings. No guidance on pagination strategies despite having six pagination parameters.
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?
Annotations already establish read-only, idempotent safety. The description adds valuable behavioral context: specific query syntax patterns, payload reduction via 'compact'/'select', and mode defaults ('data'). Does not disclose rate limits, pagination limits, or 'openWorldHint' implications regarding dynamic schemas.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but efficient single-paragraph structure front-loaded with purpose. Syntax examples are embedded without excess verbosity. Could benefit from structural separation (e.g., grouping pagination vs query logic), but every clause conveys necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and annotations covering basic safety, the description adequately covers the query DSL. However, for an 18-parameter tool with complex pagination options, the omission of pagination strategy guidance and the relationship between overlapping flags (mode vs verbose/debug/raw booleans) leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates partially by explaining 6 parameters (where, order, join, mode, compact, select) including complex syntax. However, it fails to document 12 other parameters, notably the 7 pagination controls (page, pageSize, autoPaginate, maxPages, maxResults, maxItemsTotal, maxItems) which are critical for a query tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action ('Query') and resource ('AroFlo QuoteLineItems zone'), clearly distinguishing from siblings like 'aroflo_get_quotes' by targeting the specific LineItems entity. The '(GET)' suffix reinforces the read-only nature consistent with annotations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed syntax guidance for query construction (pipe-delimited WHERE clauses, JOIN syntax) and references external documentation for valid fields. However, lacks explicit guidance on when to use this versus 'aroflo_get_quotes' or when to prefer 'autoPaginate' over manual pagination.
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?
Strong addition beyond annotations: explicitly notes 'client-side filtering' (critical implementation detail), 'auto pagination', and 'result cap' (aligning with maxResults default 2000). Annotations already establish read-only/idempotent safety, and the description adds operational context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely efficient two-sentence structure. First sentence covers purpose and filtering logic; second covers pagination. No redundant words or filler content. Front-loaded with the most critical information (open projects, client-side filtering).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a listing tool with output schema present. Covers the core 'open' filtering logic and pagination behavior. However, given 9 undocumented parameters (0% schema coverage), the description leaves significant gaps regarding the date, organization, and manager filtering capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates minimally. It implies semantics for pagination parameters (autoPaginate, maxResults, pageSize) via 'auto pagination' and 'result cap', but fails to explain 6 other parameters including sinceCreatedUtc, orgId, managerUserId, mode, verbose, and debug.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'open projects' with specific filtering logic (status/open + closeddate empty), distinguishing it from the generic sibling 'aroflo_get_projects'. However, it doesn't explicitly clarify when to use this versus the similar 'aroflo_report_open_projects_with_task_hours' sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'aroflo_get_projects' or 'aroflo_report_open_projects_with_task_hours'. While the 'open' qualifier implies usage for active projects only, there are no when-not-to-use instructions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond annotations by specifying the GET method (aligning with readOnlyHint), explaining the pipe-delimited query syntax, and documenting payload optimization via compact/select parameters. However, it omits behavioral details about pagination strategies (autoPaginate vs manual page iteration) and the implications of openWorldHint for this specific endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense and front-loaded with the core action. It efficiently packs syntax examples, format specifications, and resource references into a compact paragraph without redundant prose, though the complexity could benefit from structural separation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations covering safety (readOnly/idempotent), the description appropriately focuses on query construction. However, for a tool with 18 parameters handling complex data retrieval, the lack of pagination behavior explanation and the undocumented 'extra' object parameter leave gaps in contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage across 18 parameters, the description partially compensates by explaining the complex query DSL for 'where', 'order', and 'join' parameters (including the string/array flexibility), as well as 'mode' and 'compact' behaviors. However, critical pagination parameters (autoPaginate, maxPages, maxResults vs maxItems) and boolean flags (verbose, debug, raw) remain undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries the 'AssetCategories zone' using GET, specifying both the action (Query) and the distinct resource (AssetCategories). This effectively distinguishes it from sibling tools like 'aroflo_get_assets' by naming the specific AroFlo zone being accessed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed syntax guidance for constructing queries (pipe-delimited WHERE clauses, ORDER format), but lacks explicit guidance on when to use this tool versus alternatives such as 'aroflo_get_assets'. It does reference documentation resources for valid fields, which partially addresses usage context.
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?
Annotations declare readOnly/idempotent safety. The description adds valuable behavioral context: HTTP GET method, pipe-delimited query DSL syntax, mode options (data|verbose|debug|raw), and payload reduction via compact/select. It does not disclose rate limits, pagination cursor behavior, or the interaction between page/maxResults/maxItems limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense, information-rich single paragraph. Front-loads the zone identification. Every sentence conveys specific syntax rules or configuration options. Slightly hindered by run-on structure with quoted examples mid-sentence, but efficient given the API complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 18 parameters and 0% schema coverage, the description covers the high-complexity query DSL adequately but neglects pagination parameter relationships. References external documentation appropriately for field validation. Output schema presence excuses lack of return value description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Critical gap: 0% schema description coverage across 18 parameters. The description partially compensates by documenting the complex query syntax (where/order/join), mode, compact, and select parameters. However, it fails to explain the pagination controls (page, pageSize, autoPaginate, maxPages, maxResults, maxItemsTotal, maxItems) and boolean flags (validateWhere, verbose, debug, raw), leaving significant semantic gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specifies 'Query' (verb) and 'AroFlo TaskResources zone' (resource), distinguishing it from sibling task endpoints (taskmaterials, tasklabours). However, it does not clarify what constitutes a 'TaskResource' vs entities in those sibling zones, leaving domain ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed syntax guidance for pipe-delimited WHERE/ORDER clauses and references external docs (aroflo://docs). However, it lacks explicit guidance on when to use this aggregate zone vs specific task endpoints (taskmaterials, tasklabours) and omits pagination strategy recommendations.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, confirming safe read behavior. The description adds the GET method and valuable query syntax patterns (pipe-delimited WHERE clauses, JOIN areas), but omits behavioral details like pagination defaults, rate limits, or the effect of boolean flags (verbose/debug) that duplicate the mode parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single dense paragraph front-loads the essential operation type (Query...GET) and efficiently packs query syntax examples, mode options, and documentation references. While information-rich, the sentence structure is clear and avoids redundancy with the structured schema, though bullet points might have improved scanability for 18 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description appropriately avoids return value documentation. It covers the unique query DSL patterns well and references external field documentation. However, for a tool with 18 parameters and complex pagination options, the omission of parameter descriptions for standard pagination and utility flags leaves significant gaps in the contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description partially compensates by explaining syntax for complex parameters (where, order, join, mode, compact, select) with examples. However, it leaves 12 parameters undocumented, including pagination controls (page, pageSize, autoPaginate), validation flags (validateWhere), and the 'extra' objectPurpose, forcing agents to guess their semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb (Query/GET) and resource (AroFlo TaskTypes zone). However, it lacks domain context to distinguish 'TaskTypes' (likely classifications/templates) from sibling 'aroflo_get_tasks' (instances), which could confuse agents about which tool retrieves task categories versus actual tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies specific use (querying the TaskTypes zone) and references external documentation for valid fields, but fails to provide explicit when-to-use guidance versus the generic 'aroflo_query_zone' or when to prefer this over other filtering tools. No exclusions or prerequisites are mentioned.
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?
Annotations declare readOnlyHint, idempotentHint, and openWorldHint. The description adds context about the GET operation, payload reduction options (compact, select), and mode variations (data/verbose/debug/raw). It does not disclose rate limits, authentication requirements, or error handling behaviors that would help an agent predict failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense and front-loaded with the essential GET operation, but packs multiple syntax examples, parameter explanations, and a documentation reference into a single run-on sentence. This reduces scannability and requires parsing to extract specific parameter requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 18 parameters and complex query capabilities, the description covers the essential query syntax but leaves many boolean flags and pagination controls (maxPages, maxItemsTotal, validateWhere, extra) undocumented. Given that output schema exists and annotations provide safety context, this is minimally sufficient but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates effectively by explaining the pipe-delimited syntax for where/order/join parameters, the mode enum values, and the select array format. While pagination parameters (page, pageSize, autoPaginate) remain unexplained, the description successfully documents the complex, domain-specific query parameters that would otherwise be opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb (Query), resource (WorkOrderLineItems), and HTTP method (GET), distinguishing it from sibling tools like 'aroflo_get_workorders'. However, it doesn't explicitly clarify the relationship between work orders and their line items, leaving minor ambiguity for users unfamiliar with the domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed syntax guidance for WHERE, ORDER, and JOIN clauses, and references documentation resources. However, it lacks explicit guidance on when to use this tool versus siblings (e.g., aroflo_get_workorders) or when to use the generic aroflo_query_zone instead.
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?
Adds substantial value beyond annotations by detailing the pipe-delimited query syntax, mode options (data|verbose|debug|raw) with default values, payload reduction strategies (compact, select), and documentation resource patterns. Clarifies that WHERE/ORDER/JOIN accept both strings and arrays.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Information-dense with no wasted words, but structured as a dense run-on sentence with fragments that hinders readability. Could benefit from sentence breaks or bulleted structure for the parameter syntax explanations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for the core query functionality given the presence of an output schema, and the documentation reference mitigates some gaps. However, with 18 parameters and 0% schema coverage, leaving most pagination and control parameters undocumented represents a significant gap for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by explaining the complex query parameters (where, order, join) syntax and behavior, plus mode/compact/select. However, it fails to document ~12 other parameters including pagination controls (autoPaginate, maxPages, maxResults) and flags (validateWhere, verbose, debug).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly identifies the action (Query) and resource (AroFlo PermissionGroups zone). Naming distinguishes it from sibling tools that handle other zones (assets, clients, etc.), though it doesn't explicitly differentiate from the generic 'aroflo_query_zone' 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implicit usage guidance through detailed syntax instructions (pipe-delimited WHERE clauses, JOIN areas), but lacks explicit 'when to use' or 'when not to use' guidance relative to sibling tools like 'aroflo_get_record' or the generic query 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?
Annotations declare readOnly/idempotent/openWorld, so the description appropriately focuses on adding query syntax semantics (pipe-delimited format), response modes (data/verbose/debug/raw), and payload reduction controls (compact/select). It correctly states this is a GET operation, aligning with annotations without redundancy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single dense sentence front-loads the purpose ('Query...') followed immediately by syntax examples. Every clause provides unique value (syntax patterns, type flexibility, mode options, documentation references). Slightly dense but efficiently packed with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations covering safety profiles, the description appropriately focuses on input query syntax. However, for an 18-parameter tool with complex pagination options (autoPaginate, maxPages, maxResults), the omission of these controls leaves the description incomplete for full operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining the complex query parameters (where/order/join syntax) and mode/compact/select options. However, it fails to document 12 other parameters including pagination controls (page, pageSize, autoPaginate), validation flags (validateWhere), and the 'extra' object, leaving significant semantic gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'Query' and resource 'ClientNotes zone', distinguishing it from sibling tool 'aroflo_get_clients'. The '(GET)' annotation reinforces the read-only nature. However, it could briefly clarify what 'ClientNotes' represents (e.g., notes attached to client records) to fully distinguish from client entities themselves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides essential syntax guidance for pipe-delimited WHERE clauses and JOIN areas, implying when complex filtering is needed. However, it lacks explicit comparison to siblings (e.g., when to use this vs 'aroflo_get_clients' or 'aroflo_get_record') and doesn't mention prerequisites like valid zone slugs.
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?
Annotations establish read-only/idempotent safety; the description adds valuable behavioral context including payload optimization ('compact=true...reduce payload size'), response modes ('data|verbose|debug|raw'), and the GET method. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Information-dense single paragraph where every clause earns its place (syntax examples, defaults, resource references). While functional, breaking into distinct sentences for query syntax, pagination, and documentation references would improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 18 parameters with zero schema descriptions, the description covers the essential query DSL but leaves critical gaps around pagination behavior and the distinction between overlapping parameters (e.g., 'maxItems' vs 'maxResults'). The pointer to external docs mitigates this but doesn't fully resolve the ambiguity for immediate usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates partially by documenting the complex query syntax for 'where', 'order', 'join', 'mode', 'compact', and 'select' with concrete examples. However, it fails to explain 12 other parameters including pagination controls (page/maxPages/maxResults/maxItemsTotal relationships) and boolean flags that mirror mode options (verbose/debug/raw).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'Query' and resource 'AroFlo Locations zone (GET)', clearly identifying the target entity. However, it does not explicitly distinguish when to use this specific tool versus the generic 'aroflo_query_zone' sibling, which is important given both can query data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides syntax examples for the domain-specific query language (pipe-delimited WHERE clauses) and references external documentation resources ('aroflo://docs/api/<slug>'). Lacks explicit guidance on when to prefer this over the generic query tool or prerequisites like authentication requirements.
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?
Builds effectively on annotations by disclosing the pipe-delimited query syntax ('and|field|=|value'), response modes (data/verbose/debug/raw), and payload reduction options (compact/select). Correctly aligns with readOnlyHint=true by labeling as GET/query 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single dense paragraph front-loaded with the core action. Syntax examples ('and|field|=|value', 'field|asc') are high-value and necessary given the schema lacks descriptions. No redundant fluff, though bullet points might improve scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the domain-specific query language essential for operation, but fails to address the complex pagination behavior implied by having both 'page/pageSize' and 'maxResults/maxPages/maxItems' parameters. Given output schema exists, return values don't need explanation, but pagination strategy should be mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining syntax for 'where', 'order', 'join', 'mode', 'compact', and 'select' parameters. However, it omits explanation for 12 other parameters including pagination controls (page, pageSize, autoPaginate, maxPages) and the 'extra' extension object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States 'Query the AroFlo Priorities zone (GET)' giving specific verb, resource, and HTTP method. Distinguishes from siblings by naming the specific 'Priorities' entity, though could clarify what a 'Priority' represents in the AroFlo domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage through resource naming and refers to documentation for valid fields, but lacks explicit when-to-use guidance versus other zone query tools like 'aroflo_get_tasks' or 'aroflo_query_zone'. No prerequisites or exclusion criteria stated.
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?
Beyond the annotations (readOnlyHint, idempotentHint, openWorldHint), the description discloses the GET nature of the operation, details the payload reduction behavior (compact=true, select fields), explains the mode options (data|verbose|debug|raw), and specifies the resource URI pattern for API documentation (aroflo://docs/api/<slug>).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description packs substantial technical detail—syntax examples, mode options, and resource references—into a single dense but readable sentence. Every clause earns its place by providing actionable syntax guidance (e.g., 'and|field|=|value') that is not present in the structured schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (18 parameters, nested objects) and 0% schema coverage, the description covers the critical query-building parameters but leaves many pagination and flag parameters (autoPaginate, validateWhere, verbose, debug, raw, maxItems) undocumented. The existence of an output schema and the reference to external documentation for field values mitigate this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must carry significant weight. It successfully documents the complex query semantics for 'where', 'order', and 'join' parameters (including pipe-delimited syntax and array/string flexibility), and explains 'mode' enum values and 'select' syntax. However, it omits semantics for pagination controls (page, maxPages, maxItemsTotal) and the 'extra' object parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Query the AroFlo Substatus zone (GET)', providing a specific verb (Query), resource (Substatus zone), and HTTP method that aligns with the readOnlyHint annotation. It clearly distinguishes from siblings by targeting the specific 'Substatus' entity rather than other zones like assets or tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While it lacks explicit guidance on when to prefer this over generic alternatives like aroflo_query_zone, it provides detailed syntax patterns for the complex query parameters (pipe-delimited WHERE clauses, ORDER syntax, JOIN areas). It also references external documentation resources for valid field values, which aids in correct usage.
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?
Adds substantial context beyond annotations: explains pipe-delimited query syntax, payload reduction via compact/select, mode behaviors (data/verbose/debug/raw), and references external documentation resources for field validation. Does not contradict readOnly/idempotent hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but efficient structure front-loaded with purpose, followed by syntax examples and documentation reference. Every sentence conveys specific usage patterns. Slightly cramped but information-dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for query construction given the complexity, covering the essential domain-specific syntax. However, fails to address pagination behavior (autoPaginate, maxPages) despite these being critical for supplier list retrieval, and leaves many boolean flags unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by documenting the complex query parameters (where, order, join syntax) and mode options. However, it omits explanations for 12 other parameters including pagination controls (page, pageSize, autoPaginate) and flags (validateWhere, verbose).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Query' and resource 'AroFlo Suppliers zone' with specific HTTP method (GET). Distinguishes from other zone tools by naming Suppliers specifically, though it doesn't explicitly contrast with the generic aroflo_query_zone sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed syntax guidance for pipe-delimited WHERE/ORDER clauses and references external documentation for valid fields. Lacks explicit guidance on when to use this specific tool versus the generic aroflo_query_zone or when to prefer different modes.
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?
Annotations establish read-only/idempotent safety. The description adds substantial behavioral context: specific pipe-delimited query syntax ('and|field|=|value'), response modes (data/verbose/debug/raw), and payload reduction controls (compact/select). It does not contradict annotations and effectively explains the non-standard query DSL beyond the schema structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently packed into a single dense sentence with a documentation reference. Every clause provides unique value: HTTP method, query syntax, data types, mode options, and optimization hints. No redundancy, though the density impacts readability slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 18 complex parameters with zero schema descriptions, the description covers the essential query DSL but leaves critical gaps—particularly regarding pagination strategy (when to use autoPaginate vs manual page/maxItems) and the 'extra' parameter's purpose. The output schema existence excuses return value documentation, but input governance remains under-specified for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries significant load but delivers incomplete compensation. It thoroughly documents the complex query parameters (where, order, join) with syntax examples, and explains mode/compact/select. However, it completely omits pagination semantics (page, autoPaginate, maxPages, maxResults) and the purpose of boolean flags (verbose, debug, raw) versus the mode enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action 'Query' and specific resource 'AroFlo TaskMaterials zone', distinguishing it from sibling task-related zones (taskexpenses, tasklabours, tasks). However, it assumes domain knowledge of what a 'zone' represents in AroFlo, slightly tempering absolute 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the specific resource name (TaskMaterials), but the description provides no explicit guidance on when to choose this over siblings like aroflo_get_tasks or aroflo_get_inventory. It does reference external documentation for valid fields, which aids discovery.
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?
Reinforces read-only nature by noting '(GET)' and adds critical behavioral context missing from annotations: pipe-delimited query syntax, available response modes (data/verbose/debug/raw) with default specified, and payload optimization via compact/select options. Does not mention pagination limits or rate limiting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Information-dense single paragraph appropriately sized for the complexity (complex query DSL with 18 parameters). Front-loaded with purpose declaration. Syntax examples are efficient (pipe-delimited formats, array examples). Reference to external docs resource is useful without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers the domain-specific query language (WHERE/ORDER/JOIN syntax) which schema cannot convey, but fails to explain standard pagination parameters despite their complexity and 0% schema coverage. Output schema exists so return values don't need description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description partially compensates by documenting 6 of 18 parameters (where, order, join, mode, compact, select) with concrete syntax examples. However, it omits crucial pagination controls (page, pageSize, autoPaginate, maxPages) and utility flags (validateWhere, extra) which are essential for an 18-parameter query tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb (Query), resource (UserPosition zone), and HTTP method (GET). Clearly distinguishes from siblings by naming the specific AroFlo zone it targets, though it could briefly clarify what 'UserPosition' represents (e.g., job title vs. location).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed syntax guidance for constructing queries (pipe-delimited WHERE clauses, ORDER format), but lacks explicit guidance on when to use this specific zone getter versus the generic aroflo_query_zone or other sibling tools. No prerequisites or exclusion criteria mentioned.
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?
Adds significant context beyond readOnly/idempotent annotations: discloses filtering logic (closeddate empty), internal join pattern (project + tasktotals), and output characteristics (compact grouped). No contradictions with safety annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences, zero waste. First sentence defines scope and data returned; second explains implementation approach and output format. Front-loaded with essential filtering criteria.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for tool selection given output schema exists (no need to describe returns). However, with 14 undocumented parameters, the description fails to provide sufficient invocation guidance for a complex reporting tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Critical failure: with 14 parameters and 0% schema description coverage, the description mentions zero parameters. Does not explain date filters (sinceCreatedUtc, sinceTaskCreatedUtc), orgId, managerUserId, or mode options despite their complexity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity: states exact filter criteria (status=open, closeddate empty), resource (open projects), sub-resource (tasks), and aggregation (total labour hours). Distinguishes clearly from sibling 'list' tools by emphasizing the joined/grouped output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied guidance by describing internal behavior (fetches Projects then Tasks), hinting this is a convenience aggregation over separate calls. However, lacks explicit when-to-use/when-not-to-use guidance or named alternatives like 'aroflo_list_open_projects' for simpler 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?
Annotations establish read-only/idempotent nature. Description adds valuable context about response modes (data/verbose/debug/raw) and payload optimization (compact/select). Does not address pagination behavior, rate limits, or implications of openWorldHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence carries specific technical weight: operation definition, syntax examples for filters, mode options, payload reduction, and documentation reference. No redundant or filler text despite high information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Excellent coverage of query construction patterns, but inadequate explanation of the five distinct pagination/limit parameters and their interactions, which is critical for a data retrieval tool with 18 parameters. Output schema exists so return values need no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, description successfully explains complex query parameters (where/order/join syntax, mode options, select usage) but leaves 12+ pagination/limit parameters (maxPages, maxResults, autoPaginate, etc.) and 'extra' object completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly identifies operation (Query/GET) and specific target (AroFlo CustomHolders zone), distinguishing from sibling get_* tools via the specific zone name. Assumes domain knowledge of what CustomHolders are, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete syntax examples for pipe-delimited WHERE, ORDER, and JOIN clauses. Specifies default mode (data) and points to documentation resource for valid fields. Lacks explicit comparison to siblings (when to use vs other get_* 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?
Annotations establish read-only/idempotent safety, while the description adds crucial behavioral context: pipe-delimited query syntax, mode options (data/verbose/debug/raw), and payload optimization via compact/select. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Information-dense and front-loaded with purpose, followed immediately by syntax specifications. Efficient use of space with concrete examples ('and|field|=|value', 'field|asc'). Slightly dense as one continuous clause chain, but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 18 parameters with zero schema descriptions, the description adequately covers the unique query syntax requirements but leaves pagination behavior (page, pageSize, autoPaginate, maxResults) undocumented. Presence of output schema reduces burden for return value documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage across 18 parameters, the description successfully compensates by detailing syntax for critical query params (where/order/join as pipe-delimited strings or arrays), mode enum values, and select array formatting. Minor gap on pagination parameters (page, autoPaginate, maxPages).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it queries the 'AroFlo InventoryStockLevels zone' using GET, with specific verb and resource identification. Distinguishes from siblings by naming the specific zone, though it could better clarify when to use this versus the generic 'aroflo_query_zone' tool or 'aroflo_get_inventory'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implicit usage guidance through specific zone targeting and syntax examples, but lacks explicit 'when to use this versus alternatives' guidance regarding sibling tools. Directs users to documentation resources for valid fields, which partially offsets this gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent safety. Description adds valuable domain-specific context: pipe-delimited query syntax, JOIN area examples, mode options, payload reduction via 'compact'/'select', and critical reference to 'aroflo://docs/api/<slug>' for field validation given openWorldHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Information-dense single paragraph with no filler. Front-loaded with HTTP method and resource. Syntax examples are concrete. Slightly dense; could benefit from logical separation between query syntax and response formatting options.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for complexity: references external documentation for open-world schema discovery, explains payload optimization for potentially large datasets, and relies on existing output schema. Missing only pagination behavior details which would complete the picture given the parameter richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description compensates by detailing complex query parameters (where/order/join syntax, mode values, select format), but omits semantics for 11 parameters including pagination controls (page, autoPaginate, maxPages) and boolean flags (verbose, debug, validateWhere).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States 'Query the AroFlo WorkOrders zone (GET)' with specific verb and resource. Clear it retrieves workorders specifically, though it does not explicitly differentiate from siblings like 'aroflo_get_tasks' or 'aroflo_get_workorderlineitems' which appear related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed syntax guidance for pipe-delimited WHERE/ORDER clauses and JOIN areas, plus references documentation resources. However, lacks explicit guidance on when to select this tool versus sibling getters like 'aroflo_get_tasks' or the generic 'aroflo_query_zone'.
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?
Annotations declare readOnlyHint, openWorldHint, and idempotentHint. Description adds useful context: confirms GET method, mentions payload reduction via compact/select, and references external documentation for dynamic field validation, appropriately supporting the open-world nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Information-dense single paragraph with efficient sentence structure. Every clause provides value (syntax examples, defaults, external refs). Slightly dense; could benefit from punctuation breaks between logical sections (syntax vs pagination vs docs).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 18 parameters and 0% schema coverage, description adequately covers query/filtering semantics but omits pagination behavior (page vs autoPaginate interaction) and utility flags (validateWhere, extra). Output schema exists, so return values need not be described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description compensates for complex parameters (where/order/join syntax, mode enums, select format) but leaves 12 utility/pagination parameters (page, autoPaginate, maxPages, validateWhere, etc.) completely undocumented. Partial compensation for critical query params but significant gaps remain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb (Query) and resource (AroFlo Bills zone) with HTTP method (GET). Implicitly distinguishes from siblings like 'aroflo_get_billlineitems' by mentioning JOIN areas include 'lineitems', but does not explicitly name alternatives or when to use the dedicated lineitems tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit syntax patterns (pipe-delimited WHERE clauses, ORDER format, JOIN areas) and mode options with defaults. Lacks explicit 'when not to use' guidance or named alternatives, though the external docs reference implicitly guides users to other zones.
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?
Annotations establish read-only/idempotent safety; description adds crucial behavioral context including mode options (data/verbose/debug/raw), payload reduction via compact/select, and query construction patterns. Does not disclose rate limits or pagination behavior specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but efficient single paragraph. Front-loaded with purpose, followed by syntax examples and configuration options. No wasted words, though high information density requires careful parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for the primary query functionality given output schema exists, but significant gaps remain for 18-parameter complexity—missing guidance on autoPaginate vs manual pagination, validateWhere purpose, and extra object usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description compensates by documenting complex query parameters (where, order, join syntax) and output control (mode, compact, select), but leaves 12+ parameters (pagination booleans, validation flags, extra object) completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'Query' and resource 'AroFlo Payments zone' clearly, including HTTP method 'GET'. Effectively distinguishes from numerous sibling tools (aroflo_get_invoices, aroflo_get_bills, etc.) by specifying the Payments domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed syntax guidance (pipe-delimited WHERE clauses, JOIN areas) that implies usage context, but lacks explicit when-to-use recommendations or comparisons against sibling tools like aroflo_get_invoices.
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?
Annotations declare read-only/idempotent safety; description adds valuable behavioral context including the GET method, pipe-delimited query syntax ('and|field|=|value'), mode options (data|verbose|debug|raw), and payload reduction controls (compact/select), plus documentation resource references.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Information-dense paragraph with zero filler; front-loaded with primary action, though the single-block format packs many syntax rules together which could benefit from structural breaks for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given high complexity (18 params, custom query DSL) and 0% schema coverage, description adequately covers the domain-specific query language but has clear gaps in pagination/utility parameters; output schema exists so return values don't need description coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, description partially compensates by detailing syntax for critical params (where, order, join, mode, compact, select) including format examples, but leaves 12 parameters (pagination controls like autoPaginate, maxPages, maxItems) completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with specific verb+resource ('Query the AroFlo Quotes zone') and HTTP method ('GET'), clearly distinguishing this from 40+ siblings like aroflo_get_quotelineitems or aroflo_get_tasks by specifying the exact zone being accessed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage context through 'Quotes zone' and mentions JOIN areas like 'lineitems' (hinting at relationship to sibling aroflo_get_quotelineitems), but lacks explicit when-to-use guidance versus alternatives or prerequisites like API authentication.
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?
Aligns with readOnlyHint/idempotentHint by stating it's a GET operation. Adds valuable context about response modes, payload size reduction via compact/select, and correctly references external documentation for valid fields given openWorldHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Information-dense single sentence covers syntax, types, modes, and documentation references with minimal waste. Slight readability improvement possible by breaking into distinct sentences for syntax versus configuration versus documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 18 parameters with complex query syntax and presence of output schema, the description provides sufficient domain knowledge to construct valid queries. Appropriately delegates exhaustive field validation details to external documentation reference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Excellently compensates for 0% schema coverage by explaining pipe-delimited syntax for where/order/join with concrete examples, plus mode enums and select format. However, omits semantics for pagination controls and the relationship between mode enum and verbose/debug/raw boolean flags.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action 'Query' and resource 'AroFlo Stages zone', but does not explicitly distinguish when to use this specific zone getter versus the generic 'aroflo_query_zone' sibling tool or when to prefer it over singular 'get_record'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete syntax examples for filter clauses (where/order/join) and mentions payload optimization, but lacks explicit guidance on when to choose this tool over siblings or prerequisites like knowing valid field names from external docs.
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?
Annotations declare readOnlyHint/idempotentHint (safe to call); description adds valuable behavioral context including the GET method, four response modes (data|verbose|debug|raw), and payload reduction options (compact/select). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five information-dense sentences with zero filler. Front-loaded with the core action (Query), followed by syntax patterns, response modes, optimization flags, and documentation reference. Slightly fragmented sentence structure ('mode: ...') but highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description appropriately omits return value details. However, given 18 undocumented input parameters and complex query patterns, the description should mention pagination behavior or note that pagination parameters follow standard patterns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage for 18 parameters, requiring heavy description compensation. Description thoroughly documents complex query syntax (where/order/join), mode options, and select syntax, but omits 12 parameters including pagination controls (page, pageSize, autoPaginate, maxPages), boolean flags (verbose, debug, raw), and the 'extra' object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Query' plus specific resource 'AroFlo TaskExpenses zone' clearly identifies the operation. The '(GET)' annotation and mention of the specific zone distinguishes it from the many sibling getter tools (e.g., get_tasks, get_tasklabours) and the mutation tool (create_or_update_record).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed syntax guidance on how to construct queries (pipe-delimited WHERE, ORDER, JOIN patterns) and references external documentation resources for valid fields. However, lacks explicit when-to-use guidance versus alternative query tools like the generic aroflo_query_zone or specific task-related getters.
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?
Annotations declare safe read-only/idempotent behavior. Description adds valuable execution context: pipe-delimited clause syntax, payload reduction via compact/select, and mode variations (data/verbose/debug/raw). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but efficient. Front-loaded with purpose, followed by specific syntax examples for pipe-delimited clauses, then payload optimization hints. Every sentence provides actionable value, though the param overlap between mode enum and verbose/debug/raw booleans is left unexplained.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema is present so return values need not be described. However, given 19 parameters with zero schema coverage, the description should have addressed the pagination strategy (autoPaginate vs manual pages) and clarified the distinction between maxItems, maxResults, and maxItemsTotal. Sibling differentiation is also absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description compensates by explaining complex WHERE/ORDER/JOIN pipe-delimited syntax, mode values, and compact/select usage. However, it fails to document 13 other parameters including pagination controls (autoPaginate, maxPages), result limits (maxItems/maxResults confusion), or the required 'zone' parameter's valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb 'Query' + resource 'AroFlo zone' with scope 'arbitrary'. Effectively distinguishes from sibling tools like aroflo_get_tasks which target specific entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies flexibility via 'arbitrary zone' and references external docs, but lacks explicit guidance on when to choose this generic query tool versus the 40+ specific entity getters (e.g., 'use this when complex filtering across zones is needed, otherwise use specific getters').
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?
Adds valuable implementation details beyond annotations: specifies it uses 'parent QuoteLineItems only' to avoid double counting children, and highlights 'Credits, Extras & Variations' section. Correctly aligns with readOnlyHint=true (audit operation). Could improve by mentioning data source scope or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences with zero waste. Front-loaded with core purpose (sentence 1), followed by critical implementation detail (sentence 2) and special feature highlight (sentence 3). Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for understanding the tool's analytical purpose given the output schema exists, but insufficient for invocation given zero parameter documentation. With 20 optional parameters and no required fields, the description should indicate key identification methods (e.g., 'provide jobNumber or projectId') or filtering strategies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage across 20 complex parameters, the description fails to compensate adequately. While it implicitly references quote-related parameters via 'quote assemblies', it provides no guidance on identifying projects (jobNumber vs projectId vs projectRefno), date filter formats, matchThreshold purpose, or mode enum differences.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity with verb 'audit' and clear resource scope (project labour hours vs quote allowed hours). Explicitly distinguishes from generic get/list siblings by specifying planned-vs-actual breakdown by task and quote assembly handling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage context through specificity (quote-linked budget auditing, variations handling), but lacks explicit when-to-use guidance vs sibling reporting tools like aroflo_report_open_projects_with_task_hours. No prerequisites or alternative selection criteria stated.
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?
Annotations declare readOnlyHint and idempotentHint, but the description adds valuable implementation context by disclosing the dual-strategy approach: 'direct WHERE filters where supported' versus 'bounded scanning where necessary.' This explains the tool's performance characteristics and justifies the existence of the max*Scanned parameters without contradicting the read-only safety annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of exactly two efficiently structured sentences. The first front-loads the core purpose and input options, while the second provides critical implementation context. No words are wasted; every clause serves either functional specification or behavioral transparency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (18 parameters, multiple entity types, fallback scanning logic), the description adequately covers the primary use case but leaves significant gaps regarding secondary parameters and output structure. However, since an output schema is present, the description appropriately avoids redundantly explaining return values, keeping it minimally viable for a complex resolver tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description bears full responsibility for parameter documentation but only explicitly mentions 5 of the 18 parameters (the starting identifiers). It fails to explain the date filters (quoteSinceCreatedDate, taskSinceDateRequested), inclusion flags (includeQuoteLineItems), output modes, or pagination controls, leaving the majority of parameters semantically undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the specific action ('Resolve') and resource ('job context'), explaining that it connects job numbers with related tasks, quotes, and projects. It effectively distinguishes this tool from the numerous simple 'get' siblings (e.g., aroflo_get_tasks, aroflo_get_quotes) by positioning it as a cross-referencing resolver rather than a direct entity fetcher.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists the five valid starting identifiers (jobNumber, quoteId, quoteRefno, projectId, projectRefno), providing clear input guidance. However, it fails to explicitly state when to use this resolver versus the simpler direct getters (like aroflo_get_tasks) or when the bounded scanning fallback might be triggered, leaving usage implications largely implicit.
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?
Annotations cover safety (readOnly/idempotent), but description adds critical behavioral context: pipe-delimited syntax format for WHERE clauses, ORDER/JOIN patterns, mode options with defaults, compact/select payload reduction behavior, and references documentation location (aroflo://docs/api/<slug>) for field validation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but efficient single-paragraph structure. Front-loaded with purpose ('Query...'), immediately followed by syntax examples and format specifications. Every clause provides concrete value (syntax patterns, examples, defaults) with minimal redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for high complexity (18 params, nested objects). References external documentation for valid fields/values (critical given openWorldHint). With output schema present, it correctly focuses on input query construction rather than response format. Could briefly acknowledge pagination behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage across 18 parameters, the description partially compensates by documenting where/order/join syntax, mode enum values, compact/select usage, and extra object flexibility. However, it omits semantics for 6 pagination parameters (page, pageSize, autoPaginate, maxPages, maxResults, maxItemsTotal) and flags (verbose, debug, raw).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'Query' with resource 'AroFlo Assets zone' and HTTP method (GET). The 'Assets zone' specificity clearly distinguishes this from 40+ sibling query tools (get_tasks, get_clients, etc.) by identifying the exact zone/entity type being accessed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Lacks explicit when-to-use guidance comparing it to alternatives like aroflo_get_record or aroflo_query_zone. While the zone name implies usage (Assets), it doesn't clarify whether to use this versus generic query tools for asset data.
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?
Annotations establish read-only/idempotent safety; the description adds valuable behavioral context including the pipe-delimited query DSL syntax ('and|field|=|value'), response shaping options (compact, select), debugging modes (verbose/debug/raw), and pagination hints. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Information-dense single sentence efficiently packs protocol method, query syntax examples, type flexibility, mode options, and documentation references without redundancy. Every clause serves the agent's understanding of how to construct valid inputs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex query DSL (18 parameters, nested logic) and existing output schema, the description appropriately focuses on explaining the non-obvious query construction patterns and points to external documentation for valid fields. Missing explanations for standard pagination parameters is acceptable given the schema types clarify their purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries significant burden. It successfully explains the complex custom syntax for 'where', 'order', 'join' (pipe-delimited strings or arrays), 'mode' enum values, and 'compact/select' usage. However, it omits semantic explanation for 12 other parameters (page, autoPaginate, validateWhere, etc.), though these are mostly self-descriptive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific action: 'Query the AroFlo Tasks zone (GET)'. This provides the exact verb (Query), resource (Tasks zone), and HTTP method, distinguishing it comprehensibly from sibling tools like aroflo_get_assets or the generic aroflo_query_zone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While it does not explicitly state 'when to use vs alternatives' (e.g., when to use this instead of aroflo_query_zone), it provides rich syntax guidance (pipe-delimited WHERE clauses, JOIN areas) that implies the intended usage pattern for filtering task data. However, explicit exclusions or alternative recommendations are absent.
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?
Annotations declare readOnlyHint=true and idempotentHint=true. The description adds valuable behavioral context not in annotations: the four response modes (data/verbose/debug/raw), the payload size reduction behavior via compact=true and field selection, and the specific pipe-delimited query syntax that affects how the tool interprets inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense and front-loaded with the core purpose. Every sentence earns its place: it covers the HTTP method, query syntax specifics, mode options, payload optimization, and documentation references efficiently. Slightly complex due to the API's query language complexity, but appropriately so.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given high complexity (18 parameters, 0% schema coverage) and presence of output schema, the description adequately covers the non-obvious query syntax. However, it has clear gaps regarding pagination controls (page, pageSize, autoPaginate, maxPages) which are numerous and have non-trivial interactions, warranting mention for a complete query tool definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage across 18 parameters, the description compensates significantly by documenting the complex, domain-specific syntax for critical parameters: where/order/join (pipe-delimited format), mode (enum values with default), compact/select (purpose and format). It misses pagination parameters, but the schema types (integer/boolean) for those are self-evident, whereas the query syntax would be opaque without description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Query the AroFlo BillLineItems zone (GET)', providing a specific verb (Query), resource (BillLineItems zone), and HTTP method. It clearly distinguishes this tool from siblings like aroflo_get_bills or aroflo_get_quotelineitems by naming the specific zone/entity it targets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides rich syntax guidance for pipe-delimited WHERE clauses, ORDER clauses, and JOIN areas, which implicitly guides usage. However, it lacks explicit guidance on when to use this tool versus siblings (e.g., when to query bill line items versus bills themselves) and does not state prerequisites 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Complements annotations by explaining the query syntax pattern, payload reduction options (compact/select), and debugging modes (data/verbose/debug/raw). Correctly aligns with readOnlyHint=true by specifying GET semantics. Does not mention rate limits or pagination behavior despite complex cursor-like parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Information-dense but well-structured with embedded examples ('and|field|=|value', ['field','nested.field']). Efficiently front-loads the core action before detailing syntax patterns and external references, though the single-block format is slightly cramped.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriately delegates field validation details to external resources (aroflo://docs/api/<slug>) given the openWorldHint, but leaves significant gaps regarding pagination behavior (page, pageSize, autoPaginate, maxPages) and the 'extra' object semantics despite having an output schema available.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage across 18 parameters, the description heavily compensates by documenting the complex syntax for 'where', 'order', 'join', and 'select' parameters with concrete examples. However, it omits explanation for 7 pagination-related parameters and the distinction between the 'mode' enum and boolean verbose/debug/raw flags.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states the action ('Query'), the specific resource ('AroFlo Inventory zone'), and the HTTP method ('GET'), clearly distinguishing it from siblings that query other zones like assets, bills, or tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed query syntax examples (pipe-delimited WHERE clauses, ORDER clauses) and references external documentation for valid fields, but lacks explicit guidance on when to choose this over related siblings like aroflo_get_inventorylists or aroflo_get_inventorystocklevels.
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?
Beyond annotations (readOnly, idempotent), the description adds valuable context: it identifies the HTTP method (GET), explains response modes (data/verbose/debug/raw) with default values, describes payload size controls (compact/select), and references external documentation resources for field validation. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Information-dense single sentence with no wasted words. Front-loaded with the core action, followed by syntax examples, configuration options, and documentation references. While efficient, the density could benefit from sentence breaks for readability, but every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 18 parameters with zero schema descriptions, the description adequately covers the primary query construction interface but leaves numerous secondary parameters (pagination limits, validation flags) undocumented. Since an output schema exists, return values need not be explained, but the high parameter count and low schema coverage warrant more complete parameter documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description successfully compensates for the complex query parameters (where, order, join) by specifying syntax patterns (pipe-delimited, array/string options). It also documents the mode enum values and compact/select purposes. However, it omits semantics for pagination controls (page, pageSize, autoPaginate, maxPages) and boolean mode flags.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (Query) and resource (AroFlo MessageBoard zone), explicitly identifying the target domain object. It distinguishes itself from siblings like aroflo_query_zone by specifying the particular zone ('MessageBoard') and from other specific getters by naming the unique resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While it provides detailed syntax examples for complex parameters (pipe-delimited WHERE clauses, ORDER formats), it lacks strategic guidance on when to use this specific zone getter versus the generic aroflo_query_zone or other zone-specific tools. No explicit alternatives or exclusions are mentioned.
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?
Beyond annotations (readOnly/idempotent/openWorld), description adds crucial behavioral context: query syntax conventions (pipe-delimiters), mode options with default value, and payload optimization via compact/select flags. References external documentation resource for valid fields, acknowledging API complexity without bloating the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four well-structured sentences: purpose front-loaded first, followed by syntax examples, then mode/payload options, finally documentation reference. No redundant text; every sentence adds value beyond schema/annotations. Efficient information density given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriately complete for a complex query tool with 18 parameters and output schema present (removing need to describe return values). Annotations cover safety profile. Minor gap in paginator parameter explanations (maxItems vs maxResults distinction), but query construction documentation is thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage across 18 parameters, the description compensates partially by documenting complex query parameters (where, order, join) syntax and mode/compact/select usage. However, leaves 7 pagination-related parameters (page, maxPages, maxResults, maxItemsTotal, maxItems, etc.) undocumented and their relationships unexplained, creating potential ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'Query', resource 'AroFlo TaskLabours zone', and HTTP method '(GET)'. The specific naming of 'TaskLabours' effectively distinguishes it from 40+ sibling getter tools (e.g., aroflo_get_tasks, aroflo_get_taskmaterials).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed syntax patterns for constructing queries (pipe-delimited WHERE, ORDER, JOIN formats), which implies usage for filtered data retrieval. However, lacks explicit 'when to use this vs alternatives' guidance given multiple sibling task-related getters (tasks, taskexpenses, taskmaterials, taskresources) exist without differentiation guidance.
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?
The annotations indicate read-only, idempotent operations, which align with the 'Query' and 'GET' description. The description adds substantial behavioral context not in annotations: the pipe-delimited WHERE clause syntax ('and|field|=|value'), ORDER syntax ('field|asc'), and JOIN areas ('lineitems'). It also documents the external resource pattern ('aroflo://docs/api/<slug>') for field validation, clarifying the open-world nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four dense sentences with zero waste. Information is front-loaded (purpose first), followed by syntax examples, configuration options, and documentation references. Every sentence earns its place by conveying critical syntax patterns required to construct valid API calls.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (18 parameters, nested objects) and presence of an output schema, the description appropriately delegates field-level documentation to the external resource reference ('aroflo://docs/api/<slug>'). It provides sufficient context for the query DSL. Minor gap: it doesn't clarify the relationship between the 'mode' enum and the separate boolean verbose/debug/raw flags.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It successfully documents the complex query syntax for 'where', 'order', 'join', and explains 'mode' options, 'compact', and 'select'. However, it leaves many of the 18 parameters unexplained: the pagination controls (page, pageSize, autoPaginate, maxPages), the confusing overlapping 'maxResults'/'maxItems'/'maxItemsTotal', the 'extra' object, and the relationship between the 'mode' enum and the separate boolean flags (verbose/debug/raw).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Query the AroFlo Users zone (GET)', providing a specific verb (Query), resource (Users zone), and HTTP method context. The explicit mention of 'Users zone' effectively distinguishes this tool from the numerous sibling get_* tools for other zones (tasks, quotes, assets, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the specific zone mentioned ('Users zone'), indicating it retrieves user data. However, it lacks explicit guidance on when to use this specific zone getter versus the generic 'aroflo_query_zone' tool or when to prefer it over 'aroflo_get_record' (singular). It also omits guidance on pagination strategy (autoPaginate vs manual page iteration).
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?
Annotations confirm read-only/idempotent status, so the description appropriately focuses on adding query syntax semantics: pipe-delimited WHERE clauses ('and|field|=|value'), ORDER syntax ('field|asc'), JOIN areas ('lineitems'), and mode options with defaults. It explains payload optimization via compact/select parameters—valuable behavioral details beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense with zero filler, efficiently packing syntax examples, type flexibility notes, default values, and documentation references into a compact text. Every clause serves a purpose: explaining parameter formats, enumerating valid modes, or directing to field documentation. Minor deduction for being a single dense block that could benefit from structural separation of distinct concepts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (18 parameters, nested objects, 0% schema coverage) and presence of an output schema, the description achieves appropriate completeness by focusing on the non-obvious query syntax and deferring exhaustive field lists to the referenced API documentation ('aroflo://docs/api/<slug>'). It adequately prepares the agent to construct valid queries despite the schema's lack of descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage across 18 parameters, the description carries significant explanatory burden. It comprehensively documents the complex query parameters (where, order, join syntax), mode enum values (data/verbose/debug/raw), and compact/select usage patterns. While pagination parameters (page, pageSize, autoPaginate) and boolean flags (verbose, debug, raw) remain undocumented, the description successfully explains the non-obvious query DSL parameters that would otherwise be unusable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Query the AroFlo Clients zone (GET)'—providing a specific verb (Query), resource (Clients zone), and HTTP method. This clearly distinguishes it from the 40+ sibling tools operating on different zones (assets, invoices, tasks, etc.) and from the mutation tool aroflo_create_or_update_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies usage through the 'Clients zone' specificity, it lacks explicit when-to-use guidance versus the generic aroflo_query_zone tool or aroflo_get_record. It does reference documentation resources ('aroflo://docs/api/<slug>') for valid fields, which helps with usage context but doesn't fully address tool selection criteria.
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?
Annotations declare readOnly/idempotent, but description adds valuable context: payload reduction via compact/select, four response modes (data/verbose/debug/raw), and references external documentation resource for dynamic schema discovery. Does not explicitly address openWorldHint implications beyond the docs reference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but efficient single paragraph. Information-rich with concrete syntax examples ('and|field|=|value', 'field|asc'). No wasted words, though line breaks between conceptual groups (filtering vs pagination vs response formatting) would improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a complex query endpoint with 18 parameters and output schema present. Successfully documents the non-obvious query DSL pattern and delegates field validation to external resource reference. Missing only pagination strategy explanation to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Critical compensation for 0% schema description coverage: explains complex DSL syntax for where/order/join (pipe-delimited), mode enum values, and select array format. However, fails to document pagination controls (page, autoPaginate, maxPages) or 'extra' object purpose, leaving 10+ parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity: states 'Query the AroFlo InventoryLists zone (GET)' with clear verb (Query), specific resource (InventoryLists), and HTTP method. Clearly distinguishes from 40+ sibling tools by naming the specific zone it retrieves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed syntax guidance for pipe-delimited WHERE clauses, ORDER, and JOIN formats. However, lacks explicit guidance on when to use this vs siblings like 'aroflo_get_inventory' or 'aroflo_get_inventorycategories', or when to use autoPaginate vs manual pagination.
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?
Annotations already mark this as read-only and idempotent. Description adds valuable behavioral context not in annotations: explains pipe-delimited query syntax, mode options (data/verbose/debug/raw), compact/select for payload reduction, and references external documentation resources for valid fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Information-dense and front-loaded with the core action. Syntax examples are compact and specific. Could improve scannability with structural formatting for the multiple options, but no sentences are wasteful and all provide necessary technical detail for the complex query interface.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a complex query tool with 18 parameters and an output schema. Successfully documents the non-obvious query DSL (pipe-delimited syntax) which is essential for correct usage. Would benefit from noting pagination behavior or limits, but the reference to external docs mitigates this for field validation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description partially compensates by explaining syntax for critical parameters (where, order, join, mode, compact, select). However, it leaves 11+ parameters undocumented, including pagination controls (page, autoPaginate, maxPages), validation flags, and the 'extra' object, creating significant gaps given the high parameter count.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Query the AroFlo Invoices zone (GET)', providing specific verb (Query), resource (Invoices), and distinguishing from siblings via the explicit zone name and HTTP method. The resource identifier clearly targets invoices versus other financial entities like bills or quotes in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context through specific syntax examples for pipe-delimited WHERE clauses, ORDER clauses, and JOIN areas, which explains how to filter and retrieve invoice data. Lacks explicit comparison to siblings (e.g., when to use invoices vs. bills), but the detailed query syntax effectively guides correct invocation.
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?
Annotations declare read-only/idempotent safety. Description adds substantial behavioral context: pipe-delimited WHERE clause syntax ('and|field|=|value'), ORDER syntax ('field|asc'), JOIN areas ('lineitems'), mode options with default ('data'), and payload reduction mechanisms ('compact', 'select' with nested field notation). Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but efficient single paragraph with zero filler. Front-loaded with purpose, immediately followed by syntax examples. Technical details ('pipe-delimited', 'default: data') are high-signal. Slightly cramped structure could benefit from sentence breaks, but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for complexity: references external documentation for exhaustive field lists (practical for large APIs), explains payload optimization ('compact', 'select'), and notes output schema exists so return values needn't be described. Covers primary query patterns sufficiently despite 18 undocumented schema parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Critical compensation for 0% schema description coverage across 18 parameters. Explains complex query syntax for 'where'/'order'/'join' (pipe-delimited strings or arrays), 'mode' enum values, and 'select' array format ('nested.field'). Missing: pagination semantics (page, pageSize, autoPaginate) and boolean flags (validateWhere, verbose, debug).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb 'Query' + resource 'AroFlo Schedules zone' with HTTP method 'GET' indicated. Explicitly targets 'Schedules' which distinguishes it from 40+ sibling get tools targeting other zones like tasks, assets, quotes, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides documentation resource reference ('aroflo://docs/api/<slug>') for valid fields, implying users should check there for specifics. However, lacks explicit guidance on when to use this specific zone vs. related zones like 'aroflo_get_tasks' or 'aroflo_get_workorders', leaving selection to 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?
Annotations already declare readOnly/idempotent status. Description adds valuable behavioral context: query DSL syntax (pipe-delimited), default mode value (data), payload reduction behavior (compact/select), and references documentation resource for schema discovery. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Information-dense single paragraph packs essential DSL syntax, default values, and documentation pointers with minimal redundancy. Every phrase earns its place, though line breaks would improve readability for the multiple distinct concepts covered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a complex query tool with 18 parameters and output schema. Successfully explains non-obvious query syntax and points to external documentation for dynamic field values. Missing explicit pagination behavior description, but schema structure implies standard pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description compensates by explaining complex query parameters (where, order, join syntax) and control options (mode, compact, select), but leaves 12+ parameters undocumented (pagination flags, boolean switches like autoPaginate/validateWhere, and the relationship between mode enum and verbose/debug/raw booleans).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb (Query) + resource (AroFlo Timesheets zone) and HTTP method (GET). Clearly distinguishes from 40+ sibling get_* tools by naming the specific zone/resource (Timesheets) in the first sentence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed syntax guidance for pipe-delimited WHERE clauses, ORDER format, and JOIN areas, plus mode options. Lacks explicit 'when not to use' or sibling comparisons, but the specific resource name provides clear contextual boundaries.
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?
Annotations declare readOnly/idempotent status, but the description adds valuable context: response modes (data/verbose/debug/raw), payload reduction behavior (compact/select), and the pipe-delimited query syntax. It also references external documentation for field validation, which is crucial given the openWorldHint and lack of enum constraints in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Though information-dense and single-paragraph, every clause serves a purpose: resource identification, query syntax for three parameters, mode options, payload optimization, and documentation reference. No tautology or repetition present; efficiently front-loaded with the core operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 18 parameters with zero schema coverage and complex querying capabilities, the description adequately covers the critical parameters needed for operation (filtering, sorting, joining, field selection, response modes) and points to external resources for field values. 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries significant weight. It compensates by detailing the query syntax for 'where', 'order', and 'join' parameters (pipe-delimited format), explaining the 'mode' enum options, and documenting 'compact'/'select' usage. It omits pagination parameters (page, autoPaginate, etc.), but these are relatively self-descriptive compared to the complex query syntax it successfully documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Query the AroFlo TransactionTerms zone (GET)' providing a specific verb (Query), resource (TransactionTerms zone), and HTTP method. This clearly distinguishes it from sibling tools which query different zones (quotes, tasks, assets, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed syntax guidance for constructing queries (pipe-delimited WHERE clauses, ORDER syntax, JOIN areas) and references external documentation for valid fields. However, it lacks explicit guidance on when to use this specific zone versus the 40+ sibling get_* tools or the generic aroflo_query_zone.
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?
Annotations establish read-only/idempotent safety; description adds crucial behavioral context including pipe-delimited query syntax for WHERE/ORDER clauses, the four response modes (data|verbose|debug|raw), and payload optimization via compact/select options. Does not mention rate limits, auth requirements, or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: opening declares operation, followed by pipe-delimited syntax examples for the three main query parameters, array/string flexibility note, mode options, payload reduction guidance, and documentation reference. No redundant or wasted text despite high information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given high complexity (18 parameters, nested objects, 0% schema coverage) but presence of output schema and helpful annotations, the description adequately covers the non-obvious query formation patterns. Minor gap: lacks explanation of pagination parameter interactions (pageSize vs maxResults vs maxItems).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage across 18 parameters, the description compensates significantly by documenting the complex query syntax (pipe-delimited where/order/join clauses), mode enum values with default, and select/compact usage. However, it omits explanation for pagination controls (page, pageSize, autoPaginate, etc.) and the 'extra' parameter object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Query the AroFlo BusinessUnits zone (GET)' - specific verb (Query), specific resource (BusinessUnits zone), and HTTP method. It distinctly targets BusinessUnits versus 40+ sibling get_* tools operating on different entities (assets, clients, tasks, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that this retrieves BusinessUnits specifically, but lacks explicit guidance on when to use this entity-specific endpoint versus the generic 'aroflo_query_zone' sibling tool, or when to prefer this over 'aroflo_get_record' for specific record lookups. Usage is implied rather than explicitly guided.
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?
Annotations already indicate read-only, idempotent, open-world behavior. Description adds valuable query syntax details (pipe-delimited WHERE clauses, ORDER formats, JOIN areas), mode options with default, and payload optimization hints (compact, select). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Information-dense single paragraph with zero waste. Front-loaded with purpose, followed by query syntax specifics, optimization options, and documentation reference. Every sentence delivers actionable syntax guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a complex query tool with 18 parameters and output schema present. Covers essential query construction patterns and references external docs for valid fields. Could improve by noting pagination behavior given the multiple pagination-related parameters in schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage across 18 parameters, the description effectively compensates by explaining complex domain-specific parameters: where/order/join syntax (pipe-delimited, string/array options), mode enum values, and field selection. Does not cover pagination parameters (page, maxPages, etc.), but focuses on critical query semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with specific verb 'Query', identifies resource 'AroFlo Contacts zone', and specifies HTTP method 'GET'. Clearly distinguishes from sibling tools like aroflo_get_assets or aroflo_get_tasks by specifying the 'Contacts' zone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage context by naming the Contacts zone, helping agents select among the many aroflo_get_* siblings. However, lacks explicit when-to-use guidance, prerequisites (like authentication), or comparisons to similar tools like aroflo_get_clients.
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?
Annotations declare readOnly/idempotent safety. Description adds substantial behavioral context beyond annotations: HTTP GET method, specific pipe-delimited query syntax patterns, mode options (data/verbose/debug/raw) with default values, payload reduction via compact/select, and documentation resource references.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five dense sentences with zero waste: opens with purpose, follows with syntax examples for the three complex query parameters, notes type flexibility, documents mode/compact/select options, and closes with documentation reference. Every clause delivers actionable technical guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex query language (pipe-delimited clauses) and 0% schema coverage, the description provides sufficient examples to enable correct usage of the primary filtering mechanisms. Output schema exists (per context signals), so return values need not be described. Could enhance completeness by documenting pagination behavior (page, pageSize, autoPaginate).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description effectively compensates by detailing the complex syntax for critical parameters (where, order, join) including format examples and type flexibility (string vs array), plus mode/compact/select behavior. Omits pagination parameters but covers the non-obvious query syntax comprehensively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action 'Query' and exact resource 'AroFlo InventoryCategories zone (GET)', clearly distinguishing it from the 40+ sibling getter tools targeting different zones (assets, bills, tasks, etc.) and from the generic aroflo_query_zone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides extensive syntax guidance for constructing queries (pipe-delimited WHERE/ORDER formats, JOIN examples), but lacks explicit selection guidance comparing when to use this specific zone getter versus the generic aroflo_query_zone or other inventory-related siblings.
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?
The description confirms the GET/read-only nature which aligns with annotations (readOnlyHint: true, idempotentHint: true). It adds valuable behavioral context not in annotations: pipe-delimited syntax requirements, mode options with defaults, and payload optimization strategies. It does not disclose pagination behavior or rate limiting details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in 6 information-dense sentences with zero filler. Critical information (verb, resource, syntax examples, defaults, documentation reference) is front-loaded and immediately actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (18 parameters, nested objects, custom query syntax) and presence of an output schema, the description adequately covers the primary querying functionality and syntax. However, it lacks explanation of pagination controls (autoPaginate, maxPages) and utility flags (validateWhere, debug) necessary for full operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage across 18 parameters, the description partially compensates by explaining the complex query syntax for where/order/join, mode options, and select/compact usage. However, it leaves 12 parameters unexplained (page, pageSize, autoPaginate, maxPages, maxResults, validateWhere, verbose, debug, raw, maxItems, extra), creating significant gaps given the schema provides no descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Query the AroFlo MessageTemplates zone (GET)', providing a specific verb (Query), resource (MessageTemplates), and HTTP method. The zone-specific naming clearly distinguishes it from 40+ sibling tools like aroflo_get_quotes or aroflo_query_zone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed syntax examples for WHERE, ORDER, and JOIN clauses, explains payload reduction via compact/select, and references external documentation for valid fields. However, it does not explicitly contrast when to use this specific zone getter versus the generic aroflo_query_zone or single-record retrieval 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?
Beyond annotations (readOnly/idempotent), the description adds valuable behavioral context: the pipe-delimited syntax format for WHERE/ORDER clauses ('and|field|=|value'), the mode enum options (data|verbose|debug|raw), payload optimization via compact/select, and references to external documentation resources for valid fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Information-dense structure with zero waste: leads with purpose, follows immediately with syntax examples and format specifications, then optimization hints, ending with documentation reference. Every clause provides actionable formatting guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 18-parameter complexity and lack of schema descriptions, the description adequately covers the primary query interface. However, it should mention pagination limits (max 500 per page visible in schema) or explain the duplicate control flags (verbose/debug/raw) that mirror the mode parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by detailing the complex query parameters (where/order/join) with syntax examples and type flexibility (string or array), plus explaining mode and select. However, it omits semantics for pagination controls (autoPaginate, maxPages, pageSize) and the relationship between mode and the verbose/debug/raw booleans.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with specific verb 'Query', identifies the exact resource 'AroFlo PurchaseOrders zone', and includes the HTTP method '(GET)' to distinguish it from sibling tools like aroflo_create_or_update_record and other zone-specific getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the specific zone 'PurchaseOrders' is clear from the name and description, there is no explicit guidance on when to use this versus the generic aroflo_query_zone or aroflo_get_record. Usage is implied by the naming convention but not stated.
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?
Annotations declare readOnly/idempotent/openWorld; description adds valuable behavioral context including the GET method confirmation, payload reduction options (compact/select), debugging modes (data/verbose/debug/raw), and references external documentation 'aroflo://docs/api/<slug>' for valid field values. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely information-dense with zero waste. Single paragraph covers: purpose, three complex parameter syntaxes, type handling, mode options, payload optimization, and documentation references. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex query tool with 18 parameters and nested objects, the description appropriately delegates field validation details to the referenced external resource ('aroflo://docs/api/<slug>') while covering the critical query interface. 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates effectively by documenting the complex query syntax for 'where' (pipe-delimited), 'order', and 'join' parameters, including format examples and type flexibility (string vs array). Also clarifies 'mode' enum values/default and 'compact' purpose. Does not document pagination controls (page/pageSize) but these are relatively self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Query the AroFlo TrackingCentres zone (GET)' with specific verb and resource. The entity name 'TrackingCentres' clearly distinguishes it from 40+ sibling tools targeting different entities (tasks, assets, clients, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on HOW to use (pipe-delimited WHERE clauses, ORDER syntax, JOIN areas, mode options) but does not explicitly state when to choose this over sibling getters. However, the entity-specific naming and detailed query syntax guidance effectively communicate appropriate usage scenarios.
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:

[![aroflo-mcp MCP server](https://glama.ai/mcp/servers/0x1NotMe/aroflo-mcp/badges/card.svg)](https://glama.ai/mcp/servers/0x1NotMe/aroflo-mcp)

Score Badge

Copy to your README.md:

[![aroflo-mcp MCP server](https://glama.ai/mcp/servers/0x1NotMe/aroflo-mcp/badges/score.svg)](https://glama.ai/mcp/servers/0x1NotMe/aroflo-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/0x1NotMe/aroflo-mcp'

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