BackCrew FieldRoutes MCP Server

by jayson-svg

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Every tool is clearly either a search returning IDs for a specific entity or a get returning full records for given IDs. Entities are disjoint, and special tools like get_ticket_addons and resolve_employee_alias have distinct purposes. No ambiguity exists.
Naming Consistency5/5
All tools follow a consistent snake_case verb_noun pattern: search_<entity> and get_<entity> for every entity. Exceptions like get_ticket_addons and resolve_employee_alias still use the same verb_noun style, maintaining high consistency.
Tool Count2/5
With 39 tools, the server exceeds the 25+ threshold considered too many. While each entity pair is logical, the large number makes the tool surface heavy and could be streamlined with a generic search/get pattern.
Completeness5/5
As a read-only server, it provides search and get for all major FieldRoutes entities including customers, appointments, tickets, subscriptions, routes, payments, and more. Entity-specific addons and alias resolution fill any remaining gaps, making the read surface complete.
Average 3.6/5 across 39 of 39 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior. It includes the endpoint (POST /subscription/search) and a tier hint (readonly-owner), which adds some context. However, it does not explain pagination, response format, authentication requirements, or any side effects, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with useful metadata (endpoint, tier). It is front-loaded with the purpose and contains no fluff, though its brevity does not fully serve the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters, 0 required, no output schema, and 36 sibling tools, the description is too sparse. It does not explain filter behavior, return shape, or how it fits into the broader toolset, making it incomplete for effective selection and invocation.
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?
Schema description coverage is only 9% (only 'active' has a description). The description adds no parameter details whatsoever, failing to compensate for the 11 undocumented parameters, including nested objects like extra_filters.
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 verb 'Search' and resource 'subscriptions (recurring service plans)' and specifies that it returns matching IDs. This differentiates it from get_subscriptions, which likely returns full subscription objects, though it does not explicitly name the 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 guidance is provided on when to use this tool versus get_subscriptions or other search tools. The description only states what it does; there is no mention of 'use this when you need IDs' or alternatives to consider.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral transparency burden. It discloses the read-only nature via the tier tag and the fact that it returns IDs, but omits details on pagination, filtering behavior, return size limits, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a clear core statement. The API mapping and tier tag are brief additions, though the API mapping may be unnecessary for agent decision-making.
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?
For a search tool with 5 filter parameters and no output schema, the description is too sparse. It does not explain required context, result format, limits, or how the filters interact, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only 20% description coverage, and the description itself mentions none of the parameters. It adds no meaning beyond the schema property names, leaving ambiguous fields like 'includeData' 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 tool performs a search on tasks/alerts and returns matching IDs, with a direct API mapping. It differentiates from get_tasks by emphasizing return of IDs, but does not explicitly name any sibling alternative for comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other search or get tools. The description only states the basic operation and API mapping, without specifying scenarios, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies read-only access via 'readonly-owner' but does not explicitly state that the operation has no side effects, requires specific permissions, or describe the response format. The API mapping is an implementation detail, not behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The API mapping and tier tag add extra context without excessive verbosity. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must explain return behavior and parameter semantics. It does neither, and the subscriptionID-to-ticket relationship is left ambiguous. The description is too minimal for a tool with no structured metadata beyond the input schema.
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?
Schema description coverage is 0% and the description adds no meaning to the sole parameter 'subscriptionID'. It fails to clarify how a subscriptionID relates to a ticket, which is potentially confusing. The description does not compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('line-item addons on a ticket'), which immediately distinguishes it from sibling tools such as get_subscription_initial_addons. The verb-resource pairing is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It mentions a 'tier: readonly-owner' and the underlying POST endpoint, but does not explain use cases, prerequisites, or exclusions. The description provides no comparative context with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose that the tool returns IDs and implies read-only behavior via the 'readonly-owner' tier, but it fails to explain the meaning of 'configured flag labels', potential side effects, or permissions beyond the tier label.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that includes the core action, the resource, the return type, and an endpoint reference. Every word contributes meaning, with no unnecessary content.
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?
For a tool with two unannotated parameters and no output schema, the description is too sparse. It lacks parameter context, usage examples, and clarification of how this search relates to get_generic_flags, leaving the agent without enough information for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain the roles of officeIDs or genericFlagIDs, nor how they relate to the search. The parameter names are somewhat self-explanatory, but the description adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search') and the resource ('configured flag labels'), and specifies the outcome ('return matching IDs'). It is specific enough to distinguish from a generic 'get' operation, though it does not explicitly differentiate from the sibling get_generic_flags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While the endpoint mapping and tier hint at its nature, there is no mention of scenarios or exclusions, leaving the agent to infer usage from the name alone.
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 includes the 'readonly-owner' tier, indicating a safe read-only operation, and notes it returns IDs. Since no annotations are provided, it partially covers behavioral disclosure but lacks details on filtering mechanics or potential limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence complemented by endpoint and tier tags, with no redundant phrasing. It is concise and information-dense.
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 no output schema and no annotations, the description leaves significant gaps: parameter semantics, return structure beyond 'IDs', and usage context. It is not complete for a search tool with two optional inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not explain how 'officeID' or 'companyID' are used, whether they can be combined, or what 'matching' means. The parameter names are self-explanatory, but the description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches company offices/branches and returns matching IDs, using the specific verb 'Search'. It also maps to a specific endpoint. However, it does not explicitly differentiate from the sibling tool 'get_offices'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this search tool versus alternatives like 'get_offices' or other search tools. It simply states the action without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It includes a [tier: readonly-owner] tag and an endpoint mapping, which give some safety context. However, it does not disclose behavior such as pagination, error handling, or the effect of empty filter arrays, beyond returning IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core action, result, endpoint, and a safety tier. Each element earns its place, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 0% schema description coverage and no output schema, the description leaves critical gaps: parameter semantics, usage context, and relationship to sibling tools are all unaddressed. It only covers the basic return type, making it incomplete for confident tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two array parameters (officeIDs, regionIDs) with no descriptions, and the description does not mention them. The names are self-explanatory as filters, but the description adds no meaning about how they are combined, whether they are optional, or their format. Schema coverage is 0%, so the description should have compensated but did not.
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 verb 'Search' and the resource 'service regions', and additionally specifies that it returns matching IDs. It also includes the endpoint mapping, but it does not explicitly differentiate from the sibling get_regions tool, though 'search' implies a filtered lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that this is for filtering by office IDs or region IDs, nor does it contrast with get_regions or other search tools. The agent is left to infer the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool is a read-only operation (tier: readonly-owner) and returns matching IDs, which is useful. However, it does not mention authentication requirements, pagination, rate limits, or any other behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, well-structured sentence followed by endpoint and tier information. It is concise and front-loaded, with no unnecessary elaboration.
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?
For a complex tool with 9 parameters, nested objects, no output schema, and no annotations, the description is insufficiently complete. It only states the basic function and endpoint, leaving significant gaps around filter semantics, output structure, and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 11% for 9 parameters, and the description does nothing to compensate. Parameters like includeData and extra_filters remain unexplained, forcing the agent to infer meaning from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (search), the resource (technician routes), and the result (matching IDs). It also maps to a specific endpoint, adding confidence. However, it does not explicitly distinguish this tool from sibling tools like get_routes or other search_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_routes or other search tools. The tier hint 'readonly-owner' gives some context but does not clarify 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?
With no annotations provided, the description carries the burden of behavioral disclosure. It does add useful context by stating the API endpoint and a '[tier: readonly-owner]' hint, implying read-only access. However, it does not disclose return format details, behavior with no matches, or how parameters interact. The added context is helpful but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the action. Every word adds value, and the API endpoint and tier are neatly included without clutter. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 optional parameters and no output schema, the description is fairly minimal. It states the purpose and endpoint but lacks details on return structure and parameter combination logic. For a simple search tool it is sufficient, but it leaves important questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the two parameters (officeIDs, reasonIDs). It does not explain their meaning or how they filter results. The phrase 'return matching IDs' suggests they are criteria for matching, but the exact semantics are unclear. This is a significant gap.
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 searches configured cancellation reasons and returns matching IDs, with a specific verb (search) and resource (cancellation reasons). It also maps to the exact API endpoint. It implicitly distinguishes from sibling get_cancellation_reasons by using 'search' and 'matching IDs', though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like get_cancellation_reasons or other search tools. No context about prerequisites, typical use cases, or exclusions is provided. The only hint is the API mapping, but it doesn't help an agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It adds useful context via the 'readonly-owner' tier and endpoint mapping, but lacks details on filtering behavior, pagination, or response format, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence stating the tool's purpose, followed by the endpoint and tier tag. Every piece earns its place with 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?
With 8 parameters, nested objects, no output schema, and no annotations, a one-line description is severely incomplete. The agent is left without critical information on how filters combine, what includeData does, or what the return payload looks like.
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?
Schema description coverage is only 25%, and the description adds no parameter-level meaning. It does not explain undocumented parameters like fname, lname, officeIDs, includeData, or extra_filters, so the agent has almost no guidance on how to construct a valid search.
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 it searches for employees (technicians, sales reps, office staff) and returns matching IDs, giving a specific verb and resource. However, it does not explicitly distinguish from the sibling get_employees, leaving some ambiguity about when to use search vs. retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching employees by criteria, but it provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions or alternative tools like get_employees.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses the HTTP method and a 'readonly-owner' tier, hinting at read-only behavior. However, it does not explain potential behaviors like filtering semantics, result limits, or ownership scope beyond the cryptic tier label.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence stating the purpose and result, plus endpoint and tier metadata. Every word earns its place without redundancy or filler.
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 7 parameters, a nested extra_filters object, and no output schema or annotations, this description is insufficient for correct invocation. It lacks parameter semantics, usage guidance, and details about response format beyond 'IDs', making it inadequate for an agent to use the tool effectively.
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?
The description provides zero explanation of the 7 input parameters, and schema coverage is 0%. Parameter names like customerIDs and dateStart are self-explanatory to some extent, but the description does not compensate for the lack of schema documentation, leaving an agent without clear guidance on how to construct valid queries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search for customer notes') and the result ('return matching IDs'), distinguishing it from sibling tools like get_notes which likely return full data. The endpoint mapping ('POST /note/search') adds technical specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as get_notes or other search tools. The description does not mention any exclusions, prerequisites, or typical use cases, leaving the agent to infer from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool is read-only (tier: readonly-owner) and returns IDs, which is useful. However, it doesn't explain behaviors like pagination, response structure, or what happens with no filters, leaving gaps for a 12-parameter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences (or one sentence plus a bracket) that front-load the core purpose. It includes the endpoint and tier with no fluff, every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too minimal for a tool with 12 parameters and no output schema. It doesn't explain the return format (e.g., array of IDs), how filters combine, or suggest next steps like fetching full data with get_appointments. Leaves the agent with many unanswered questions.
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?
Schema description coverage is only 8% (only status has a description). The description itself doesn't explain any of the 12 parameters, including cryptic ones like includeData and extra_filters. The agent gets almost no guidance on parameter meaning beyond vague names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for appointments and returns matching IDs, with a specific verb and resource. It distinguishes from get_appointments by highlighting that it returns only IDs, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a search tool that returns IDs, but it does not explicitly state when to use this tool versus alternatives like get_appointments. The 'return matching IDs' hint suggests a follow-up fetch, but no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses the read-only nature via '[tier: readonly-owner]' and the return type ('matching IDs'), which are useful behavioral facts. However, it does not describe pagination, filtering behavior, or any side effects, leaving gaps for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence followed by the endpoint and tier. Every word contributes to understanding the tool's core function, with no redundancy or irrelevant detail.
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?
With no output schema and no annotations, the description must provide more context to be complete. It mentions return of IDs but omits any details about the six optional filters, response format, or usage constraints. For a search tool with this many parameters, the description is under-specified.
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?
Schema description coverage is 0%, and the description adds no parameter information. The six parameters (officeIDs, chemicalID, customerID, includeData, appointmentID, chemicalUseIDs) are left entirely to the schema, with no explanation of how they relate to the search or what includeData does. The description fails to compensate for the lack of schema 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 clearly states the tool searches records of chemicals applied on appointments and returns matching IDs. This distinguishes it from sibling tools like search_chemicals (chemical catalog) and get_chemical_uses (retrieve all records), and the specific verb-resource pair is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a search/filter operation by saying 'Search records' and 'return matching IDs', but it does not explicitly contrast with alternatives (e.g., get_chemical_uses for all records) or state when to prefer this tool. No exclusions or conditions 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?
With no annotations, the description carries the transparency burden. It adds 'return matching IDs' and '[tier: readonly-owner]', which indicate the operation is read-only and returns identifiers, but it does not discuss pagination, empty-result behavior, filtering semantics, or permission nuances.
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 concise sentences: the core purpose is front-loaded, followed by the endpoint mapping and a security tier hint. Each sentence adds distinct value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, nested object, no output schema, no annotations), the description is too sparse. It lacks information about parameter usage, return format, filtering behavior, and edge cases, making it inadequate for reliable invocation.
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?
Schema description coverage is only 9% (only 'status' is described), and the description provides zero parameter guidance. Ambiguous parameters like 'includeData' and 'extra_filters' remain completely unexplained, so the description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'Search' with a clear resource ('tickets (invoices)') and states the outcome ('return matching IDs'). It distinguishes from sibling tools like get_tickets by indicating this is a search operation that returns IDs rather than full objects.
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 verb 'search' and mention of 'matching IDs' imply this is for filtering, but the description offers no explicit when-to-use guidance or comparison with alternatives like get_tickets. The tier hint at least signals it is read-only for the owner.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the transparency burden. It discloses that it maps to POST /chemical/search, returns matching IDs, and includes a tier hint (readonly-owner) indicating access level. However, it does not mention pagination, rate limits, or behavior when no filters are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core action and endpoint. 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?
For a simple search tool with no output schema, the description covers the return type and endpoint but lacks parameter semantics and when-to-use guidance. Sibling tools further complicate selection, but the core behavior is clear.
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?
Schema has 0% description coverage, and the description does not explain the two parameters (officeIDs, chemicalIDs). The agent must infer their meaning from names alone; the description adds no semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the chemical/product library and returns matching IDs, with an explicit endpoint mapping. This distinguishes it from sibling tools like get_chemicals, which likely retrieve full records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_chemicals or search_chemical_uses. The tier tag indicates readonly access but does not offer contextual usage directions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden. It discloses the read-only owner-level access via the tier tag and the 1000-ID limit, which are useful behavioral constraints. However, it doesn't describe behavior for invalid or missing IDs, response format, or any additional side effects. It's minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three short sentences, each purposeful: core action, API mapping, and permission tier. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple ID-based fetch tool, the description covers purpose, parameter semantics, and the endpoint. The absence of an output schema isn't a problem since 'full document records' implies the return. However, it lacks guidance about error handling and alternative search tools, making it slightly less 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?
The schema only declares documentIDs as an array of numbers. The description adds 'up to 1000' and frames them as document IDs, giving meaning beyond the schema. Since schema coverage is 0%, this compensation is valuable, though it doesn't specify array nesting or type details beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full document records for up to 1000 IDs, specifying the resource and scope. However, it doesn't explicitly contrast with sibling search_documents, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no mention of when to use this tool versus search_documents or other get_* siblings. The 'Maps to POST /document/get' is an implementation detail, not usage guidance. The existence of search_documents implies this is for ID-based retrieval, but that distinction is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the HTTP method (POST) and a 'readonly-owner' tier, which hints at read-only behavior. However, it does not explain the effect of the active or useBothKeys parameters, nor what happens when both employeeID and employeeLink are provided. The description adds some context but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by the endpoint and tier tag. It is concise, front-loaded, and free of filler. Every element earns its place by either stating the purpose or providing actionable metadata.
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?
This tool has no output schema, no annotations, and a modest description. The description does not explain return values, error behavior, or parameter interactions. With 4 parameters and a specific purpose, the description is too minimal to be considered complete for an agent to use confidently without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only employeeLink has a schema description). The description mentions 'employee ID or external link,' which partially maps to employeeID and employeeLink, but it leaves active and useBothKeys completely unexplained. With low schema coverage, the description should compensate more thoroughly but only covers half the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Find the employee IDs associated with an employee ID or external link.' It specifies a verb (find), a resource (employee IDs), and the input scope (employee ID or external link). This distinguishes it from sibling tools like search_employees or get_employees, which handle broader employee lookups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied but not explicit. The description explains what the tool does but does not mention alternatives or when to choose this over search_employees or get_employees. No exclusions are given, so it earns a 3 for implied usage rather than a 4 or 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses a 'readonly-owner' tier, indicating read-only access and authorization level, and notes that matching IDs are returned. It does not cover pagination, error behavior, or parameter combinations, but the tier and output type provide useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences plus a tier tag. Every part adds value: what it does, the API mapping, and the access tier. No fluff or repetition of schema details.
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 no output schema, no annotations, and only partial parameter descriptions, the description is incomplete for an agent to invoke correctly. It lacks parameter semantics and usage alternatives. The agent may not know how to combine type, entityID, and genericFlagIDs, or when to choose this over get_flag_assignments.
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 only 33% (only 'type' has a description), and the description does not elaborate on entityID or genericFlagIDs. The description's phrase 'which flags are assigned to which records' hints at the meaning, but it does not explicitly define parameters or their roles. With low schema coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches flag assignments and returns matching IDs. It uses a specific verb ('Search'), identifies the resource ('which flags are assigned to which records'), and specifies the output ('matching IDs'). This distinguishes it from siblings like get_flag_assignments by emphasizing search behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this when you need to find which flags are assigned to records. However, it does not explicitly mention when not to use it or offer alternatives (e.g., get_flag_assignments for direct retrieval). The API mapping adds context but not comparative 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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It adds useful context via the '[tier: readonly-owner]' tag, indicating a safe, read-only operation, and specifies that the tool returns IDs. This goes beyond a simple statement of purpose and aids the agent in understanding side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a tag, delivering essential information (purpose, return type, endpoint, and safety tier) with no wasted words. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 optional parameters, no output schema, and no annotations, the description is incomplete. It explains what the tool does and returns IDs, but does not cover parameter semantics, pagination, or any filtering behavior, making it insufficient for confident correct invocation.
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?
The description provides no information about the 7 input parameters, which have 0% schema description coverage. It only says 'search for payments' without hinting at available filters like date range, office IDs, or payment IDs. This leaves the agent with no guidance on how to construct valid queries beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool searches for payments and returns matching IDs, with a clear verb and resource. This distinguishes it from get_payments, which presumably retrieves specific payments, and other search_* tools by specifying the resource and return type.
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 when to use the tool ('search for payments') but does not explicitly mention alternatives or when not to use it. While the verb 'search' suggests filtering use cases, there is no explicit comparison to sibling tools like get_payments for retrieving known IDs.
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 are absent, so the description carries the full burden. It discloses a read-only operation via 'List' and the permission tier 'readonly-owner', which is useful context. However, it does not describe response format, error handling, or the meaning of 'initial-service addons', leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a single sentence plus endpoint and tier in brackets. Every element earns its place: action, scope, API mapping, and permission level. No redundancy or 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?
With one parameter, no output schema, and no annotations, the description covers the core purpose and permission level. However, it omits any description of return values (since no output schema exists) and lacks guidance on when to use this over sibling tools. It is adequate for a simple list operation but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the sole parameter 'subscriptionID'. While the parameter name is intuitive, the description adds no meaning beyond the schema and fails to compensate for the lack of schema 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 clearly states a specific action ('List') and resource ('initial-service addons on a subscription'), distinguishing it from sibling tools like get_ticket_addons. The explicit API mapping to POST /subscription/getInitialAddOns adds precision and reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions. The tier 'readonly-owner' gives a permission context, but no alternative tools are mentioned, so usage guidance is only implied by the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a read-only nature via '[tier: readonly-owner]' and indicates the return type ('matching IDs'). However, it does not mention authentication requirements, rate limits, or the exact behavior when combining customerIDs and documentIDs (e.g., AND vs OR).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two short sentences plus a tag) and front-loads the primary action. Every sentence earns its place, with no fluff or repetition.
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 2 params, no output schema, and no annotations, the description provides the core purpose and a basic return description ('matching IDs'). However, it lacks parameter semantics, combination logic, and any details about pagination or result format, making it only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only says 'attached to customers' but does not explain that customerIDs filters by customers or documentIDs limits to specific document IDs. The meaning of both parameters is left ambiguous, and the interaction between them is undisclosed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Search'), resource ('documents attached to customers'), and output ('return matching IDs'). It distinguishes itself from sibling get_documents by specifying the attachment to customers and the search/filter behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context (searching documents by customer) but does not explicitly mention alternatives or when-not-to-use. The presence of a sibling get_documents implies a distinction, but the description itself does not reference it. Usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals the tool is a read operation, the ID limit, and the API endpoint, but does not explain behavior for invalid IDs, partial failures, or response payload structure. Tier hint 'readonly-owner' adds some context.
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 compact, front-loaded with the main action, and includes useful endpoint and tier metadata. However, the lack of parameter details is a gap, though it remains concise for its size.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no output schema, and no annotations, yet the description only covers the ID parameter and the general purpose. It omits behavior for missing IDs, parameter implications, and the response format, making it only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only adds meaning to appointmentIDs by noting the 1000-ID limit. The parameters includeTargetPests and includeCancellationReason are left completely unexplained, providing no clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full appointment records using appointment IDs, with a specific limit of up to 1000 IDs. This distinguishes it from search-based tools like search_appointments which likely query by criteria rather than IDs.
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?
Implied usage is clear: use when you have appointment IDs and need full records. However, it does not explicitly contrast with search_appointments or mention alternatives, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden. It adds a 'tier: readonly-owner' hint and the endpoint mapping, indicating a read-only operation with potential owner-level access. However, it does not disclose authentication specifics, error behavior, side effects, or the exact structure of returned records, leaving notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one succinct sentence followed by the endpoint mapping and tier notation. Every segment contributes value (what, limit, endpoint, access level) and is immediately front-loaded. It is highly concise without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (single parameter) and the description captures its core purpose, but it lacks details about the return format ('full records' content), pagination, error handling, and differentiation from search_chemicals. Since there is no output schema, such context would be valuable to make the description fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines 'chemicalIDs' as an array of numbers with no description and 0% schema coverage. The description compensates partially by stating 'up to 1000 IDs', which clarifies the maximum array length and that elements are IDs. However, it does not explicitly state these are chemical IDs or provide format details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full chemical/product records for up to 1000 IDs, using a specific verb and resource. It also maps to the underlying endpoint, which removes ambiguity. This distinguishes it from sibling search tools by focusing on direct ID-based retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when IDs are available ('up to 1000 IDs') and the tool is read-only, but it does not explicitly state when to use this versus the sibling search_chemicals tool or other searches. No exclusions or alternative tool names are provided, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the readonly nature via '[tier: readonly-owner]', the batch limit of 1000, and the underlying POST endpoint. However, it does not mention error handling for invalid IDs, partial results, or response format, which are relevant behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: one sentence for the main purpose, followed by two brief technical notes (endpoint and tier). Every segment adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-IDs tool with a single parameter and no output schema, the description covers the core purpose, limit, and safety level. It could be enhanced by specifying behavior for missing IDs or response structure, but overall it provides sufficient context for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that 'ticketIDs' are ticket/invoice IDs and adds a critical constraint of 'up to 1000', which is not present in the schema. This adds meaningful context beyond the raw array-of-numbers definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get full ticket (invoice) records for up to 1000 ticket IDs.' This is a specific verb-resource combination that distinguishes it from search_tickets by emphasizing ID-based retrieval. However, it does not explicitly name sibling tools or contrast with search semantics, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when specific ticket IDs are known, but it lacks explicit guidance on when to choose this over search_tickets or other alternatives. The tier note and endpoint mapping provide context but do not clearly state 'use this when you have IDs' versus other criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds useful behavioral context: the 1000-ID cap and the '[tier: readonly-owner]' tag, which signals read-only access and ownership requirements. Missing are details about response format, error handling, or behavior for invalid/nonexistent IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence followed by the endpoint and tier metadata. It is front-loaded and every element ('full records', 'up to 1000 IDs', endpoint, tier) adds value with zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter batch getter with no annotations and no output schema, the description covers the essential aspects: the endpoint, the record limit, the access tier, and the scope of returned records. It could be more complete by explicitly contrasting with the search variant, but overall it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate for the bare array-of-numbers schema. It clarifies that the parameter holds flag-assignment IDs and imposes a limit of 1000, adding meaning beyond the schema. It does not elaborate on edge cases or the exact expected format for the IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and clearly identifies the resource as 'full flag-assignment records' with a precise scoping constraint ('up to 1000 IDs'). It also maps to the underlying endpoint, which distinguishes it from the sibling search_flag_assignments tool by indicating a bulk getter by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a list of flag-assignment IDs to retrieve, and mentions the 1000-ID limit. However, it does not explicitly state when to use this tool over search_flag_assignments or provide exclusions/alternatives, leaving the choice partially implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral transparency. It adds useful context by revealing the underlying HTTP method and endpoint ('POST /genericFlag/get') and the access tier ('readonly-owner'), which implies a read-only operation with owner-level permissions. However, it does not disclose behaviors like error handling, response format, or effect of exceeding the 1000-ID limit, which would be valuable. The tier and endpoint are genuine additions, but coverage is incomplete.
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 exceptionally concise: a single sentence stating the action and limit, followed by a technical mapping and tier tag. Every word earns its place, and the key information is front-loaded. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no nested objects), the description is reasonably complete. It covers what the tool does, the input constraint, the underlying endpoint, and the access tier. What's missing is a description of the return format, but since no output schema is provided and this is a straightforward get-by-ID operation, the absence is acceptable. It could benefit from a note about what 'full flag-label records' contain, but overall it provides enough context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes only an array of numbers for genericFlagIDs with no coverage of meaning (0%). The description compensates by indicating these IDs correspond to 'flag-label records' and introduces a max of 1000 IDs, which is not in the schema. This adds meaningful context, but it could go further (e.g., explaining the structure of a flag-label record or any formatting requirements). Still, the description provides the most critical semantic: the IDs identify flag labels and are batch-limited.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get full flag-label records for up to 1000 IDs.' It specifies a specific verb ('Get'), a concrete resource ('flag-label records'), and includes a key constraint (up to 1000 IDs). This distinguishes it from sibling search tools like search_generic_flags, which likely perform query-based retrieval rather than batch get by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: you should call this tool when you have a list of specific generic flag IDs and need the full records, up to a limit of 1000. However, it does not explicitly mention when to use an alternative (e.g., search_generic_flags) or provide exclusion criteria. The 'up to 1000 IDs' hints at a batch size limit but does not frame it as guidance versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool maps to POST /serviceType/search, is 'readonly-owner' (indicating no mutation and permission level), and returns IDs. This is more transparent than a bare description, though it lacks details on pagination, filtering semantics, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main verb and resource. It uses two sentences plus a compact endpoint and tier tag. Every element adds information without fluff, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a clear purpose, endpoint, and return type (IDs), but with no output schema and 3 optional parameters, it leaves gaps in how to structure queries. It is adequate for a basic understanding but not fully complete for a tool with multiple optional filters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters with 0% description coverage. The description does not explain the meaning or usage of typeIDs, category, or officeIDs. The examples of service types are not tied to specific parameters, so the description provides minimal value beyond the raw schema field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and the resource 'service types', provides concrete examples (Quarterly Pest Control, Termite Inspection), and specifies that it returns matching IDs. This distinguishes it from the sibling tool get_service_types, which likely returns all service types, by emphasizing the search/filter behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for filtering/querying service types by providing examples and stating it 'return[s] matching IDs', but it does not explicitly mention alternatives, exclusions, or when to prefer this over get_service_types. No explicit when/when-not guidance is given, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description adds useful behavioral context: the 'readonly-owner' tier indicates safe read access, the 'up to 1000' limit sets expectations, and the endpoint mapping to POST /customer/get clarifies the underlying operation. It does not detail error handling or response structure, but the read-only and limit constraints are significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the core action is in the first sentence, followed by two compact qualifiers (endpoint mapping and tier). Every element adds useful information without redundancy.
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?
For a tool with 6 parameters, 0% schema coverage, no output schema, and no annotations, the description is incomplete. It does not explain the function of the include flags, what 'full customer records' entails, or the response format. An agent would lack crucial details for correctly invoking the tool with the optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning only for the 'customerIDs' parameter (up to 1000 IDs), but the five 'include*' parameters are not explained; their names suggest boolean flags, yet the description does not clarify their purpose or accepted values. This is a significant gap given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('full customer records'), and the input scope ('up to 1000 customer IDs'). It distinguishes itself from sibling tools like search_customers by specifying batch retrieval by IDs rather than search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when you have customer IDs and need full records, with a batch limit of 1000. It implies usage for retrieval rather than search, although it does not explicitly name alternatives or exclusion cases like search_customers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It discloses the read-only nature via '[tier: readonly-owner]', the payload limit, and the HTTP endpoint. It does not describe error behavior or the exact return format, but the key safety traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two phrases plus tags, with the core purpose front-loaded. No wasted words; each element ('full', 'up to 1000', 'POST /payment/get', 'readonly-owner') adds context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 param, no output schema), and the description covers the main function, the limit, and access context. However, without an output schema or a description of the return structure, the agent may not know exactly what fields are included, though 'full' implies completeness. Sibling tools provide further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has a single param paymentIDs with no description (0% coverage). The description adds that the IDs are payment IDs and that there is a maximum of 1000, giving meaning beyond the raw schema. It doesn't detail valid ranges or duplicates, but compensates for the schema gap.
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 function: retrieving full payment records for up to 1000 payment IDs. It identifies the resource (payments) and scope (by ID, limit). However, it does not explicitly contrast with sibling search_payments, so it lacks explicit differentiation.
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 usage is implied: when you have payment IDs and want full records. It mentions a limit but does not specify when to prefer this over search_payments or other get tools. There are no explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It states the tool returns IDs and includes a '[tier: readonly-owner]' hint, but it doesn't explicitly mention that the search is read-only or explain pagination/limits. The includeData parameter's behavior is left to the schema, so transparency is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary purpose and immediately pointing to the alternative. No unnecessary 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 16 parameters, no output schema, and no annotations, the description is far too brief. It doesn't explain the search semantics, parameter combinations, result limits, or the meaning of the read-only tier. The description covers only the most basic purpose and one sibling relationship.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, and the description adds no parameter-level semantics beyond the schema. It doesn't clarify how the filter parameters interact (e.g., AND/OR), what fields are searchable, or how to use extra_filters effectively. The description's brief mention of returning IDs doesn't help understand the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search for customers and return matching IDs'. It also distinguishes itself from the sibling tool get_customers by explicitly directing users there for full records, providing a clear verb+resource+outcome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'use get_customers to fetch full records' indicates when to use this search tool versus the alternative. It also provides the underlying endpoint mapping and tier, implying a read-only 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?
With no annotations provided, the description carries the full burden. It discloses a limit ('up to 1000'), a permission tier ('readonly-owner'), and the underlying HTTP method, but it does not describe the exact return structure, handling of invalid IDs, or behavior when exceeding the limit. This partial disclosure is helpful but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary action and resource. The additional notation about HTTP mapping and tier is compact and useful, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple bulk retrieval tool with one parameter and no output schema, the description covers the essential aspects: purpose, parameter meaning, limits, and permission scope. It lacks explicit usage guidance and return format details, but given the low complexity, it is largely 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?
The schema only defines officeIDs as an array of numbers with no description. The description adds crucial meaning by identifying them as 'office IDs' and specifying a maximum count of 1000. This goes beyond the schema, though it does not cover other constraints like uniqueness or minimum size.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get full office records'), the resource ('office records'), and the scope ('up to 1000 office IDs'). This distinctly differentiates it from sibling tools like search_offices, which imply a search operation rather than bulk retrieval by known IDs.
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 usage context is implied: use when you have a list of up to 1000 office IDs and want complete records. However, there is no explicit mention of when not to use it or reference to alternative tools like search_offices, which leaves the guidance to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It adds the 'readonly-owner' tier and the 1000-ID limit, which are useful behavioral constraints. However, it does not disclose error behavior, authorization specifics, or what 'full' records include, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loaded with the core purpose, and provides bonus context (API mapping and tier) in a compact form. Every sentence earns its place with no unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple batch-get tool with one parameter and no output schema, the description is mostly complete. It covers the limit, API route, and safety tier. However, it stops short of explaining response shape or error semantics, which would be helpful given the absence of an output 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?
Schema coverage is 0%, and the description compensates by explicitly noting the 1000-ID limit, which is not in the schema. The parameter name 'typeIDs' and the phrase 'service type records' clarify that the array contains service type identifiers, adding meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get'), resource ('full service type records'), and a scope/limit ('up to 1000 IDs'). It distinguishes itself from sibling search tools like search_service_types by emphasizing retrieval by IDs for full records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have known IDs and want full records, but it does not explicitly state when to use this tool versus search_service_types or other get_* tools. The API mapping and tier hint at context but do not provide direct alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the full burden of behavioral disclosure. It adds valuable context by mapping to POST /note/get and including the tag '[tier: readonly-owner]', which indicates a read-only operation and the owner permission level. This goes beyond a vague 'get' statement and informs the agent that the tool is safe for read operations, though it does not detail error handling or response format.
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 concise and front-loaded with the primary purpose, followed by the API mapping and a tier tag. Each element adds information without redundancy. However, the tier tag '[tier: readonly-owner]' is somewhat cryptic and could be misinterpreted, slightly detracting from ideal clarity. Overall, it is well-structured but not perfectly polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description provides sufficient context: it states the operation, the input limit, the HTTP mapping, and the read-only scope. It does not explicitly describe the return value, but for a 'get full records' tool, this is reasonably implied. The description is comprehensive enough for an agent to invoke it correctly without additional 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?
The schema only shows a single array parameter 'noteIDs' with no description (0% coverage). The description compensates by explaining that the parameter contains note IDs and that it supports 'up to 1000' of them, adding a critical limit and clarifying the intended use of the array. This is meaningful semantic information that the schema does not provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get full note records'), the resource ('note records'), and the scope ('for up to 1000 note IDs'). It distinctly differentiates from sibling tools like 'search_notes' by emphasizing 'full' records and ID-based retrieval, while also providing the mapping to POST /note/get.
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 phrase 'for up to 1000 note IDs' implies that this tool is used when you have specific IDs to fetch, but it does not explicitly state when to use it instead of search-based alternatives. No alternative tools are mentioned, nor is there a when-not-to-use condition. The guidance is implicit rather than explicit, so it lacks the clarity required for a score of 4 or 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds valuable context: an input limit of 1000 IDs, the HTTP method (POST), and an access tier ('readonly-owner'). However, it does not disclose error behavior, response format details, or confirm absence of side effects beyond the implied read-only nature. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus two short tags. It front-loads the core action and resource, includes the endpoint, and notes the access tier without any fluff. Every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter batch fetch with no output schema or annotations, the description covers the key aspects: what it retrieves, the input limit, the HTTP mapping, and the tier. 'Full region records' hints at the return value. It could mention alternatives or error handling, but overall it is complete enough for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines only a 'regionIDs' array with no descriptions. The description compensates by explaining the parameter's purpose (region records) and the maximum count (1000), adding meaning beyond the raw type. With only one parameter, this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('full region records'), and the specific input scope ('up to 1000 region IDs'). This distinguishes it from sibling tools like search_regions, which imply searching rather than direct ID-based retrieval. The endpoint mapping adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a list of region IDs, which is distinct from searching. However, it does not explicitly name alternatives (e.g., 'use search_regions to find regions by criteria') or state when not to use this tool. The tier hint provides some context but not exclusionary 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?
Despite lacking annotations, the description adds valuable behavioral context: '[tier: readonly-owner]' discloses access level and read-only nature, 'up to 1000 route IDs' indicates a batch limit, and 'Maps to POST /route/get' reveals the HTTP method. This goes beyond the name and schema, though it could mention handling of invalid or excess IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences—and front-loads the core purpose ('Get full route records'). The API mapping and tier annotation are appended efficiently without 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?
For a one-parameter tool with no output schema, the description is adequate: it states the action, resource, limit, and access level. However, 'full route records' is vague regarding the return structure, and there is no mention of error behavior or partial success scenarios, leaving a small gap.
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 by clarifying that the sole parameter 'routeIDs' consists of route IDs and imposes a maximum of 1000. This adds meaning beyond the raw schema type definition, although it could explicitly reference the parameter name for absolute clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get full route records' with a specific resource (routes) and a constraint (up to 1000 route IDs). It distinguishes itself from sibling search tools like search_routes by focusing on retrieval by IDs, and the 'Maps to POST /route/get' adds technical specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you have route IDs and need full records. However, it does not explicitly mention alternatives like search_routes for finding routes by criteria, nor does it state when not to use this tool. The batch limit gives some context but not exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides useful behavioral context: it notes the operation is 'readonly-owner' indicating permission level and safety, and it sets a limit of 1000 IDs, which is a rate/usage constraint. However, it does not detail behavior on invalid IDs or partial failures, so it's not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus two brief qualifiers (endpoint and tier). It is front-loaded with the main action and resource, and every phrase adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is reasonably complete: it covers the operation, the ID limit, the HTTP mapping, and a permission tier. It lacks a description of the return format (no output schema exists), but this is a gap given the promise of 'full subscription records'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds critical parameter meaning by stating the array contains 'subscription IDs' and is limited to 1000. This clarifies the purpose of the subscriptionIDs parameter beyond the raw schema, although it could specify whether IDs must be unique or how overflow is handled.
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 specifies a clear action and resource: 'Get full subscription records' for up to 1000 subscription IDs. This distinguishes it from siblings like search_subscriptions (which implies searching) by emphasizing retrieval by IDs. The explicit endpoint mapping further clarifies its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: use when you have subscription IDs to fetch. However, it does not explicitly state when to use this tool instead of alternatives like search_subscriptions, nor does it mention exclusions or prerequisites. The endpoint mapping provides some context but no clear 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?
With no annotations provided, the description carries the burden of safety and behavior. It discloses a read-only tier ('readonly-owner'), an endpoint mapping, and a batch size limit (1000 IDs), which are meaningful behavioral traits. It does not elaborate on invalid-ID handling or output structure, but the added constraints provide solid transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and resource, followed by essential technical details (endpoint and tier). Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a straightforward get-by-IDs tool with one parameter and no output schema. The description covers the key aspects: purpose, batch limit, and endpoint. It omits details about the exact shape of 'full records,' but given the tool's simplicity, the provided context is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. Although it does not syntactically detail the 'reasonIDs' parameter, it clarifies that 'IDs' are cancellation reason IDs and sets a practical limit of 1000, effectively explaining the parameter's meaning and constraint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a clear resource ('full cancellation reason records'), and a scope ('up to 1000 IDs'). It distinguishes itself from sibling 'search_cancellation_reasons' by emphasizing 'full records' and retrieval by IDs.
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 clearly implies the tool is for fetching full records when you have reason IDs, and the 'up to 1000 IDs' limit sets a usage boundary. However, it does not explicitly name alternative tools or when not to use it, yet the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the operation is read-only via the '[tier: readonly-owner]' tag and mentions it maps to POST /chemicalUse/get, which provides context about the underlying API. This is useful, but the tier notation is not fully explained and potential failure modes (e.g., exceeding 1000 IDs) are not mentioned.
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 entire description is two short sentences with no filler. The first sentence states the core behavior; the second adds endpoint and tier information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple bulk-fetch tool with one param and no output schema, the description provides essential details: the operation, the ID limit, and read-only nature. It lacks a direct mention of the alternative search_chemical_uses, but that is secondary. The tool is adequately specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero descriptions for the single parameter, so the description must clarify semantics. The phrase 'for up to 1000 IDs' explains the array's purpose and adds a cardinality limit, which goes beyond the schema. However, it does not name the parameter explicitly or describe the element type, though the schema covers that, so it is sufficient but not extensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), specifies the resource ('full chemical-use records'), and states a clear scope ('up to 1000 IDs'). It also distinguishes itself from search_chemical_uses by indicating this is a direct ID-based retrieval for complete records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have specific chemical-use IDs and need full records, and the 'up to 1000 IDs' constraint sets expectations. However, it does not explicitly contrast with the sibling search_chemical_uses or state when NOT to use this tool, so it earns a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description adds useful context: batch limit of 1000 IDs, maps to POST /employee/get, and tier 'readonly-owner' indicating read-only access.
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?
Single concise sentence that front-loads the purpose and includes relevant constraints and endpoint mapping without unnecessary detail.
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?
Simple one-parameter tool with no output schema; description covers the essential behavior and limits, though it omits response format or error details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description clearly identifies the parameter as employee IDs and adds the critical constraint of up to 1000 IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves full employee records for up to 1000 employee IDs, which distinguishes it from sibling search tools like search_employees.
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?
Implies usage when you have specific employee IDs and need full records, but does not explicitly mention alternatives like search_employees or resolve_employee_alias.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly labels the tool as '[tier: readonly-owner]', signaling a safe read-only operation, and mentions the limit of 1000 IDs. It does not cover error behavior or pagination, but the key safety profile is clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The main action, limit, endpoint mapping, and tier are all included in a compact, front-loaded format. Every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-IDs tool with one parameter, no output schema, and no annotations, the description covers purpose, usage context, behavioral safety, and parameter semantics. It could elaborate on edge cases or response format, but the essential details are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, taskIDs, with zero description coverage. The description compensates by explaining that these are task/alert IDs and capping the count at 1000, which adds meaning beyond the raw schema type. For a single parameter, this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a resource ('task/alert records'), and a clear scope ('up to 1000 task IDs'). This distinguishes it from sibling tools like search_tasks and other get_* tools that operate on different resources or retrieval modes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Get full task/alert records for up to 1000 task IDs' establishes a clear use case: when the caller has specific task IDs and needs complete records. It does not explicitly name alternatives or exclusions, but the 'Maps to POST /task/get' and tier information add context. Lacks explicit when-not guidance, so not a 5.
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:

[![backcrew-mcp-fieldroutes MCP server](https://glama.ai/mcp/servers/jayson-svg/backcrew-mcp-fieldroutes/badges/card.svg)](https://glama.ai/mcp/servers/jayson-svg/backcrew-mcp-fieldroutes)

Score Badge

Copy to your README.md:

[![backcrew-mcp-fieldroutes MCP server](https://glama.ai/mcp/servers/jayson-svg/backcrew-mcp-fieldroutes/badges/score.svg)](https://glama.ai/mcp/servers/jayson-svg/backcrew-mcp-fieldroutes)

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/jayson-svg/backcrew-mcp-fieldroutes'

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