fieldwork-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation2/5
Many tools appear to serve the same purpose, such as what_products_do_we_carry and list_materials, how_much_money and get_financial_summary, and whats_on_the_schedule and list_calendar_work_orders. The natural-language question tools overlap heavily with the structured API tools, creating ambiguity about which to use. An agent would struggle to pick the right tool consistently.
Naming Consistency2/5
The tool names mix full-sentence questions (how_many_customers, who_owes_me_money) with standard verb_noun patterns (get_invoice, list_materials, search_customers). There is no consistent convention; even similar actions use different verbs such as find_customer vs search_customers. This inconsistency makes it harder to predict tool names.
Tool Count2/5
With 28 tools, the server exceeds the 25-tool threshold for 'too many' and includes many near-duplicate question-answering and structured-data tools. The count feels inflated by redundancy rather than justified by distinct functionality.
Completeness4/5
The server provides broad read-only coverage across customers, work orders, invoices, materials, routes, technicians, and summaries. It lacks any create/update/delete operations, which may be acceptable for an analytics assistant, but there are minor gaps such as no all-invoices list endpoint and no single-technician fetch.
Average 3.6/5 across 28 of 28 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering safety. The description adds no additional behavioral context such as pagination behavior, default sorting, or required permissions. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence 'Search invoices.' is extremely concise and front-loaded, but it is under-specified for a tool with 5 parameters and an output schema. It wastes no words but also contributes little beyond the tool name.
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 multiple optional filters, pagination, an output schema, and many sibling tools, the description is inadequate. It does not mention filtering capabilities, search fields, or differences from get_invoice, leaving the agent without enough context to invoke it optimally.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 5 optional parameters with 0% description coverage. The description does not explain how 'query' works, what filters like customer_id or service_location_id do, or how page/per_page function. Parameter names are self-explanatory to a degree, but the description adds no confirmation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search invoices' names the verb 'search' and resource 'invoices', but lacks any scope or filtering details, making it vague. It does not explicitly distinguish from sibling get_invoice, though 'search' implies plural or filtered retrieval.
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_invoice or search_customers. There is no mention of query syntax, use cases, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, establishing a safe read-only operation. The description adds that the tool returns 'jobs (and completions)' per route, which gives some context beyond the annotations. However, it does not disclose aggregation behavior, handling of routes with zero jobs, or date boundary semantics. With strong annotations, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using one sentence with embedded questions to convey the purpose. It is front-loaded with the user-facing questions, making the primary intent immediately clear. There is no wasted wording, though the informal structure sacrifices some precision.
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 three optional date-related parameters and an output schema present, the description should clarify how to specify the date range and what the response contains. The output schema covers return values, but the total lack of parameter guidance leaves the tool difficult to invoke correctly. The description is too thin for a tool with multiple configurable parameters.
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 input schema has three parameters (days, end_date, start_date) but the description provides no explanation of them. Schema description coverage is 0%, and the phrase 'date range' is not enough to understand how days relates to start_date/end_date, defaults, or conflicts. The description completely fails to compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing route-level metrics ('Jobs (and completions) per service route') and answers the natural language questions 'How are my routes doing?' and 'Which route is busiest?'. It distinguishes from siblings like list_service_routes (which likely just lists routes) and who_did_the_most_jobs (technician-focused). However, it lacks a direct verb like 'get' or 'list', relying on question phrasing.
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 example questions imply a use case (route performance analysis over a date range), but there is no explicit guidance about when to use this tool versus alternatives such as get_operations_summary or how_is_business_doing. No exclusions or alternative tool names are mentioned, so the usage context 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering safety and side effects. The description adds the date format (YYYY-MM-DD) and date-range scoping but does not disclose other behavioral aspects like sorting, pagination, or result limitations. Given the annotations, this is adequate but not rich beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no fluff or redundant information. It efficiently conveys the core purpose and date format, earning maximum structure points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having annotations and an output schema, the description is too sparse. It fails to explain two boolean parameters and provides no context about the tool's relationship to similar sibling tools like 'whats_on_the_schedule' or 'search_work_orders'. For a tool with four parameters and no schema descriptions, this leaves significant gaps in understanding.
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 clarifies the date format for start_date and end_date. The boolean parameters 'only_workpool' and 'with_workpool' are completely unexplained, leaving substantial ambiguity about their meaning and effect.
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 uses a specific verb ('List') with a clear resource ('calendar work orders') and a date range indicator. However, it does not distinguish this tool from sibling tools like 'search_work_orders' or 'whats_on_the_schedule', so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or comparative context with sibling tools. The only inferred usage is via the date range parameters, but there is no explicit 'use this when' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive). The description adds the ISO date format requirement, which is useful. However, it does not disclose what data the summary includes or how optional filters affect results, leaving some behavioral 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, efficient sentence with no wasted words. It is front-loaded with the purpose and includes a concrete date format example, earning a top score for conciseness.
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 4 parameters and an output schema, the description is too minimal. It lacks details about optional filtering, report contents, and how it compares to similar report tools. The agent may struggle to use it correctly in nuanced scenarios.
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 description gives meaning to start_date and end_date via the date range and ISO format mention, but it completely omits branch_id and service_route_id. With 0% schema coverage, these parameters remain unexplained, making this 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 identifies the tool as an 'Operations summary report' and specifies the date range scope. It is specific enough to distinguish it from other report tools, though it doesn't explicitly name siblings.
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 a date-range summary but provides no explicit when-to-use guidance, exclusions, or alternatives. It conveys the intended context but not decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it provides a 'snapshot for a date range,' which is useful context. It does not describe return format or aggregation details, but the output schema exists and annotations carry the burden.
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, with example questions front-loaded to quickly convey intent. It is two sentences long and every part adds value. It could be slightly more structured, but it avoids unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and strong annotations, the description is mostly adequate for a simple financial summary. However, parameter semantics are completely unexplained, and with many financial sibling tools, more context on what 'financial summary' includes (e.g., revenue, expenses, profit) would improve completeness.
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%; the three parameters (days, end_date, start_date) have no descriptions. The description only mentions 'date range' but does not explain how days relates to start/end dates or the expected date formats. Since the description must compensate for the schema gap, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: answering revenue/financial questions with a 'financial summary snapshot for a date range.' This is a specific verb+resource. However, it does not distinguish itself from the sibling tool 'get_financial_summary,' which may serve a similar 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 example questions imply when to use this tool (when users ask about revenue or money made), but there are no explicit when-not-to-use instructions or references to alternatives like 'get_financial_summary' or 'how_is_business_doing.' Guidance is implied through examples rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description only repeats 'read-only' and adds no additional behavioral context such as pagination behavior, ordering, or filtering semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's purpose and read-only nature. There is no unnecessary wording or redundancy beyond the read-only flag, which is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema and strong annotations, the description is minimally sufficient for an agent to understand the core action. However, it lacks usage guidance and parameter semantics, making it only adequate rather than fully 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 does not explain the meaning or usage of customer_id, page, per_page, or body_contains. It only implies that notes are associated with a customer, adding little value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('notes on a customer'), immediately clarifying the tool's function. It also distinguishes itself from sibling customer-focused tools by focusing on notes rather than general customer data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_customer or search_customers. There are no stated exclusions, prerequisites, or context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is covered. The description adds the date-range scoping and default behavior, which is useful context beyond annotations, but it does not describe return format or pagination. With annotations present, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with only two brief lines. The example questions provide quick context, and the core functionality is stated in a single sentence. It could be slightly more structured, but it is efficient and front-loaded.
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 3 optional parameters and an output schema (which reduces the need to document return values), the description is minimally adequate. However, it does not explain how to actually specify a date range (e.g., whether start_date and end_date are needed together, or how days interacts with them), nor does it distinguish this from the many sibling schedule-related tools. This is a gap for a tool with no required params and 0% schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'date range (default 7 days)', which vaguely relates to the days/start_date/end_date params but does not explain their interplay, accepted formats, or which param controls what. This leaves significant ambiguity for the agent.
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 provides a 'work-order overview for a date range', and the example questions ('What's on the schedule?', 'How many jobs this week?') make the purpose obvious. However, it lacks a specific verb like 'list' or 'retrieve', and does not differentiate from sibling tools such as list_calendar_work_orders.
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 example questions imply usage for schedule/job count inquiries, and the 'default 7 days' hints at a time-based query. But there is no explicit guidance on when to use this vs. alternatives, no exclusions, and no mention of how it relates to list_calendar_work_orders or search_work_orders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a behavioral detail about the 'plain' flag using the show_plain endpoint, which is useful, but it does not explain the behavior when plain=false or other runtime aspects like errors or response formats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose and a concise technical detail. There is no fluff or redundancy, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, output schema, and annotations, the description covers the basic purpose. However, it does not disambiguate from closely related sibling tools (search_work_orders, get_work_order_service_report) or fully explain the 'plain' flag, leaving gaps in context for proper tool selection.
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 partially explains 'plain' by relating it to an endpoint, but does not explain work_order_id or what plain=false does. This leaves the agent with incomplete understanding of the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Fetch one work order,' which is a specific verb+resource combination. The word 'one' helps differentiate it from search_work_orders, but it does not explicitly name sibling tools or contrast itself, so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a single work order is needed, and the required work_order_id parameter suggests having the ID. However, there is no explicit guidance on when to use this tool versus alternatives like search_work_orders or get_work_order_service_report, and no exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. However, the description adds no behavioral context beyond the parenthetical clarification, such as return format, pagination behavior, or any filtering scoping.
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 short sentence plus a clarifying parenthetical. Every word earns its place, and the parenthetical adds useful scoping 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?
Given the tool's simplicity (no parameters), rich annotations, and available output schema, the description is sufficient for a basic list operation. It could improve by noting whether it returns all routes or any ordering, but the output schema likely covers return structure.
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 zero parameters, so there is nothing to document. The baseline for 0 params is 4, and the description does not add parameter-related ambiguity.
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 uses a specific verb ('List') and resource ('service routes'), clarified parenthetically as 'technician routes'. It clearly states what the tool does, but it does not explicitly distinguish this from sibling tools like 'how_are_my_routes_doing', which may also relate to routes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or relationships to sibling tools such as 'how_are_my_routes_doing' or 'list_services'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the agent knows this is a safe read operation. The description adds a useful content detail ('often includes treatment details') but does not disclose other behavioral aspects such as return structure or error conditions. This adds some value but is minimal.
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, tightly-worded sentence that immediately conveys the tool's purpose. It is front-loaded with the key verb and resource, with no wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema present, annotations provided), the description is adequate for a basic read operation. However, it lacks explicit usage guidance and does not connect to sibling tools, making it not fully complete for an agent that needs to decide between related tools.
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 one parameter (work_order_id) with 0% schema description coverage, so the description must compensate. It does not mention the parameter at all, nor provide any format or usage details. The parameter name is self-explanatory, but the description adds no semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses an explicit verb ('Fetch') and resource ('service report for a work order'), clearly distinguishing it from the related 'get_work_order' sibling. The parenthetical about treatment details adds useful 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?
The description provides no guidance on when to use this tool versus alternatives like 'get_work_order' or 'list_work_order_unit_records'. It does not state any exclusions or prerequisites, 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?
Annotations already declare the tool as read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds the phone-number criterion but gives no additional behavioral context (e.g., exact vs partial match, result limits, or open-world semantics) beyond what annotations imply.
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 uses no extraneous words. It is front-loaded and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no nested objects) and has an output schema plus rich annotations. The description covers the core purpose sufficiently, but it lacks sibling differentiation and any nuance about the search behavior, which slightly reduces completeness.
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 does clarify that 'phone' is the search key by stating 'by phone number', adding meaning beyond the bare parameter name. For a single simple parameter, this is adequate.
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 ('Find') and the resource ('a customer'), and the specific search criterion ('by phone number'). However, it does not distinguish this tool from sibling tools like find_customer or search_customers, which likely have overlapping purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does, with no mention of prerequisites, exclusions, or comparisons to other customer search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this as read-only, idempotent, open-world, and non-destructive. The description adds useful context about free-text search fields, date format flexibility, and a hint to keep page size modest. It does not describe return behavior, but the output schema covers that; overall, moderate additional value.
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 compact docstring with a clear summary line followed by a structured list of arguments. It is front-loaded and free of fluff, with each line earning its place. Minor informality like 'whatever Fieldwork indexes' slightly reduces polish.
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 thoroughly covers parameters, but lacks usage context compared to the 28 sibling tools. It does not mention output ordering, pagination behavior, or when to choose this over find_customer or search_customer_by_phone. Adequate for a parameter reference, but not a complete guide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining all 8 parameters with formats, defaults, and meaning. For example, it specifies accepted date formats for start_date, end_date, and updated_after, and defines query as free-text. This is a strong, complete parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search Fieldwork customers' which clearly identifies the action and resource. It is a search operation on customer data, but does not distinguish itself from sibling tools like find_customer, get_customer, or search_customer_by_phone, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its alternatives. It only lists parameters without any exclusions or typical use cases. Given the presence of similar search tools, this is a significant gap.
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 annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the domain-specific 'Fieldwork search text' but does not disclose additional behaviors such as matching logic, case sensitivity, or result limits, providing limited value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with examples, followed by a one-sentence definition. It avoids unnecessary verbosity, though the example-first structure is slightly unconventional. Every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter search tool with an output schema and safety annotations, the description is mostly sufficient. The main gap is the lack of differentiation from the sibling 'search_customers' tool and no mention of the 'limit' parameter's behavior, which would be needed for full contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no field descriptions), so the description must compensate. It clarifies that 'query' accepts a name or Fieldwork search text, adding meaning to that parameter. However, the 'limit' parameter is not addressed, leaving a gap in semantics for that field.
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 explicitly states it searches for customers by name or Fieldwork search text, with concrete example queries ('Do I have a customer named ___?', 'Find customer Smith'). The verb 'search' and resource 'customers' are clear, but it does not distinguish itself from the sibling 'search_customers' tool, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The example questions provide clear context for when to use this tool—when you need to find a customer by name or a textual query. However, it does not mention when not to use it (e.g., for exact ID lookups via get_customer) or explicitly name alternatives, though the examples imply the typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the ISO date format detail, which is parameter guidance rather than additional behavioral disclosure. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the tool's purpose and key parameter format with zero wasted words. It is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and rich annotations, the one-sentence description is largely adequate for a simple report tool. It could mention branch_id filtering or the kind of financial summary (e.g., profit/loss), but these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It mentions date range and ISO date format, which helps for start_date/end_date, but it does not explain branch_id or how the date parameters interact. Partial compensation for the parameter 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 provides a financial summary report for a date range, giving a specific resource and scope. However, it does not explicitly distinguish itself from siblings like get_operations_summary or how_is_business_doing, which may also summarize business/financial data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The date-range and ISO-format guidance implies when to use this tool, but there is no explicit statement of when not to use it or which alternative to choose. It lacks comparisons to sibling tools that might overlap in purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful context about the output content (completed/cancelled jobs, production value) and the plain-English nature of the response. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with example questions, followed by a compact summary of the output metrics. It is efficient but could be slightly cleaner in formatting the example questions.
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 read-only snapshot tool with an output schema and strong annotations, the description covers the core purpose and output content. However, the complete lack of parameter semantics and absence of usage exclusions leave gaps for an agent trying to invoke it correctly, especially with three optional date-related 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 parameter coverage is 0%, and the description does not explain how 'days', 'end_date', or 'start_date' affect the snapshot. The only hint is the example 'this month', but no explicit parameter meaning is provided, so 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool answers natural-language questions like 'How is business doing?' and 'How many jobs did we finish this month?', and identifies the specific output: a plain-English operations snapshot with jobs completed, cancelled, and production value. This distinguishes it from financial or route-specific siblings, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool by providing example user questions that should trigger it. It implies this is for high-level business snapshots rather than detailed reports, but it doesn't explicitly mention exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and no destructive action. The description adds behavioral context that unfiltered searches may return large result sets (via the date-range advice), which is not in the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no filler. The first states the purpose, the second gives a clear actionable optimization tip. Every word 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?
With 7 optional parameters and zero schema descriptions, the description is notably incomplete. It fails to explain the query parameter, pagination fields, or boolean filters (work_pool, current_technician). The presence of an output schema helps, but selection and correct usage of the tool remain under-specified.
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 carries the burden. It only elaborates on start_date and end_date (including format and purpose), while ignoring query, page, per_page, work_pool, and current_technician. Parameter names hint at meaning, but the description adds no actual semantics for the majority.
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 work orders/service appointments, using a specific verb and resource. It clearly differentiates from the sibling 'get_work_order' (single record) and 'list_calendar_work_orders' (calendar view) via the search term.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It advises using start_date and end_date to keep results small, which is useful usage guidance. However, it does not explicitly state when to use this tool instead of alternatives like get_work_order or search_invoices, nor any 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to restate safety. It adds the context that data is 'configured in Fieldwork', which is a small behavioral detail, but it does not describe return format or any other traits beyond 'lists'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with example questions and a clear statement of function. No wasted words; appropriate for a zero-parameter read-only tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and an existing output schema, the description provides enough context about purpose and data source. It could be slightly ambiguous whether 'products' and 'chemicals' are identical, but the examples help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty properties). The description adds meaning by specifying the domain (materials/products in Fieldwork), which is helpful; no param details are needed.
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 uses a specific verb 'Lists' and resource 'materials/products configured in Fieldwork', and provides example questions that clarify intent. However, it does not explicitly distinguish from sibling tool list_materials, which likely performs a similar task.
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 through example questions ('What products do we carry?', 'What chemicals are in our catalog?'), but it does not state when to prefer this tool over list_materials or other catalog tools. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. However, the description adds no behavioral context beyond what the name and schema state (e.g., no mention of 'not found' handling, response shape, or error conditions). With no added context beyond annotations, this earns a low score.
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, efficiently worded sentence that conveys the essential operation without filler. It earns the highest score for brevity and clarity.
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 1-parameter fetch with an output schema and robust annotations, the description is largely complete. However, given the presence of multiple customer lookup siblings, a mention of when to choose this tool over search/find alternatives would improve completeness. Still, the simplicity keeps the gap small.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description only says 'by ID', which minimally reinforces that the customer_id parameter is the lookup key. The schema already provides the parameter name and type, so the description adds slight value but doesn't compensate for missing details like format or constraints.
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 'Fetch one customer by ID' uses a specific verb ('Fetch') and resource ('customer'), clearly indicating a single-object read by primary key. This distinguishes it from sibling tools like search_customers or find_customer, which imply broader lookup capabilities.
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 specific customer ID and need that exact record. Though it doesn't explicitly mention alternatives or exclusions, the 'by ID' phrasing provides clear context that differentiates it from search/list tools among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe read operation (readOnlyHint=true, destructiveHint=false, idempotentHint=true). The description adds no additional behavioral context beyond the basic action, so it does not contribute extra transparency but is consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, 'Fetch one invoice by ID,' that immediately conveys the action and resource. It is concise, front-loaded, and 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 lookup tool with one parameter, annotations, and an output schema, the description is sufficient but not exhaustive. It could mention that search_invoices is for broader queries, but the current context is complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining the parameter beyond 'by ID.' However, the parameter 'invoice_id' is self-explanatory and the schema provides integer type and required status, so the minimal semantics are adequate.
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 is specific: 'Fetch one invoice by ID.' It clearly states the verb (fetch), the resource (invoice), and the scope (by ID). This distinguishes it from sibling tools like 'search_invoices,' which implies searching rather than direct lookup.
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 specific invoice ID, but it does not explicitly state when to use this tool versus alternatives like 'search_invoices' for queries without an ID. No exclusions are provided, making guidance minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context about the catalog scope and sample fields, but does not disclose other behavioral traits like ordering, pagination, or update frequency. This is adequate but minimal for a simple list 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, well-structured sentence that front-loads the action ('List materials/chemicals') and includes the key context ('Fieldwork catalog'). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters), strong annotations, and presence of an output schema, the description is complete. It names the specific resource and gives example return fields, which is sufficient for an agent to understand what the tool does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is complete. Per rubric, the baseline is 4 when there are no parameters, and the description does not need to explain parameters. The description's mention of 'name, EPA #, etc.' hints at return fields but does not affect parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('materials/chemicals in the Fieldwork catalog') with example fields (name, EPA #). It is clear and unambiguous, but it does not explicitly distinguish itself from sibling tools like 'what_products_do_we_carry', which could overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use when you need to see materials/chemicals in the catalog. However, it provides no explicit guidance on when not to use it or alternatives, such as the similar-sounding 'what_products_do_we_carry'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral detail about the computation: it aggregates open invoice balances and ranks customers by amount due. This goes beyond the annotations, but it does not cover finer details like pagination or date ranges; the presence of an output schema mitigates that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler. The first sentence provides natural-language entry points, and the second explains the action. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only aggregator with one optional parameter and an output schema, the description covers the essential purpose. It could mention that top_n controls the list length or clarify 'open' means unpaid, but overall it is sufficient for a competent agent.
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 one parameter, top_n (integer, default 10), with no description (0% schema coverage). The description does not mention the parameter or explain how it controls results, though it implies a 'top customers' limit. Since the description fails to compensate for the schema's lack of documentation, this dimension is weak.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly answers three natural-language queries and states the core action: 'Totals open invoice balances and lists top customers by amount due.' This clearly differentiates it from siblings like search_invoices (which would search individual invoices) and get_financial_summary (broader financial view).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via the questions it answers ('Who owes me money?'), but it does not explicitly state when to use this tool over alternatives like search_invoices or get_financial_summary. There is no mention of exclusions or alternative tools, so it relies on 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?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds minimal context ('configured in Fieldwork') but does not disclose additional behaviors such as return format or filtering behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words, effectively communicating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a valid output schema and no required parameters, the description is sufficient for a simple listing tool. The context of 'configured in Fieldwork' provides domain scope, and annotations cover safety and open-world behavior.
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 is empty with zero parameters, so the description has no parameter burden. Per rubric, 0 params yields a baseline of 4; the description's reference to 'service types' aligns with the schema's implicit scope.
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 'List' with resource 'service types configured in Fieldwork', clearly distinguishing it from sibling tools like 'list_materials' or 'list_service_routes'. It effectively states the tool's function in one sentence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving service types but does not provide explicit guidance on when to choose this tool over alternatives or any exclusions. The verb 'List' suggests a read-only enumeration, but no alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond annotations by explaining that usages are nested on unit records and that no standalone material-usages index exists, helping the agent understand the API structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the primary action stated first. Every sentence adds value—the first states the function, the second provides essential context about the API data model. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a list operation with strong annotations and an output schema. It explains why this tool exists for material usage, but it does not mention pagination behavior or default limits, which are relevant context for a list endpoint.
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 lack of parameter documentation. It mentions 'work order' in relation to work_order_id, but gives no explanation of the page or per_page parameters, leaving their behavior undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'unit records for a work order', clearly stating what the tool does. It also distinguishes this tool from siblings by noting it is the main read path for material usage, which is not available as a standalone index.
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: 'This is the main read path for material usage' implies when to use this tool. However, it does not explicitly name alternatives or state when not to use it, stopping short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description adds context by specifying the ranking behavior ('by completed jobs') and the date-range limitation, which goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with purpose and example queries. Every sentence adds value, with no redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered. The core purpose and date-range scope are stated. Minor gaps remain around the definition of 'completed jobs' and parameter interaction, but these are not critical given the structured annotations and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'for a date range' but does not explain how start_date, end_date, and days interact (e.g., whether days is an alternative to explicit dates or what the default range is). This is insufficient for the three 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 explicitly states the tool 'Ranks technicians/routes by completed jobs for a date range' with a specific verb and resource. It also provides example questions that frame the purpose, clearly distinguishing it from siblings like who_are_my_technicians.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context via example queries ('Who did the most jobs?', 'Who's my top technician?') and mentions the date range scope. It does not explicitly name alternatives, but the examples signal when this tool is appropriate compared to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as read-only and idempotent. The description adds a useful safety note ('no secrets') and clarifies the entities returned, but doesn't describe response format or pagination—behavioral details that would add more value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences that front-load the trigger questions and immediately state the outputs. Every phrase contributes meaning ('no secrets' adds a valuable qualifier).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless tool with an output schema, the description is fully sufficient. It covers the scope of returned data and adds a relevant safety qualifier, leaving no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema requires no explanation, so the baseline is 4. The description doesn't need to elaborate further and doesn't attempt to, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Answer', 'Lists') and names the exact resources (technicians, office users, service routes), making the tool's function unmistakable. It also implicitly distinguishes from performance-focused sibling tools like 'who_did_the_most_jobs'.
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 example questions ('Who are my technicians?', etc.) give explicit context for when to use this tool. However, it doesn't state exclusions or point to alternatives like 'list_service_routes' for route-only queries, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains important behavioral details beyond the annotations: days are ignored if start_date is set, end_date defaults to today, and material_name works as a filter. This adds context on parameter precedence and time range handling. The readOnlyHint and idempotentHint align with the description, and no contradictions are present.
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 well-structured: it opens with example questions, gives a one-sentence summary, and then provides a concise parameter list. Every sentence adds value, and the format is easily scannable. It is neither too terse nor overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, parameter semantics, and key behavioral nuances (e.g., date range handling, filtering). An output schema exists, so not explaining return values is acceptable. It could mention what happens when no data matches, but the current level is sufficient for effective selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides zero property descriptions, but the description's Args section thoroughly explains each parameter—including defaults, format (YYYY-MM-DD), precedence rules, and an example material name. This fully compensates for the schema's lack of descriptions, giving the agent clear guidance on how to construct valid calls.
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: 'Totals logged material/chemical usage from completed jobs.' It also provides example questions that make the purpose immediately understandable. This distinguishes it from sibling tools like what_products_do_we_carry or list_materials, which focus on inventory rather than usage.
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 example questions ('How much product was used?', 'What chemicals did we use this month?') clearly indicate when to use the tool. The description also specifies the scope (completed jobs) and optional filters, providing clear context for when it applies. It does not explicitly mention alternatives or exclusions, but the usage context is well 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so they cover the safety profile. The description adds value by disclosing the underlying endpoint (GET /v3.1/profile) and the redacted output format, which goes beyond the annotation set.
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—four short sentences, each delivering distinct information: purpose, usage priority, HTTP method/endpoint, and output nature. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only health check with an output schema, the description fully covers the essential context: what it does, when to run it, how it operates (GET call), and what to expect in the response. It is complete for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for this dimension is 4. The description doesn't mention parameters, but none exist, so there is nothing missing. Schema coverage is trivially 100%.
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 with a specific verb ('Verify') and resource ('Fieldwork credentials'). It distinguishes itself from sibling tools by positioning as a health check, explicitly saying 'Run this first if other tools fail'.
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?
It provides explicit when-to-use guidance: 'Run this first if other tools fail.' This is a direct instruction for usage context, even though it doesn't name alternative tools specifically, it implies the priority relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds useful behavioral detail beyond annotations: it counts 'every customer' and 'breaks down by status,' which clarifies the output shape without needing to infer from schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first gives natural-language examples for triggering the tool, and the second states the core behavior and a usage preference. Every sentence earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema present, the description fully covers what an agent needs: the exact query intent, the scope ('every customer'), and the output feature (status breakdown). It also includes explicit sibling differentiation, making this a self-contained, complete description for its 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 tool has zero parameters, so the baseline is 4 per the rubric. The description correctly focuses on behavior rather than parameter details, as there is nothing to document. It also points out the breakdown by status, which compensates for the lack of parameter-driven options.
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 ('counts') and resource ('every customer in Fieldwork'), immediately clarifying the tool's purpose. It also distinguishes itself from search_customers by explicitly naming it as the alternative for total-count questions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to prefer this tool ('for total-count questions') and names the alternative ('search_customers'), giving the agent clear decision guidance. This goes beyond mere implication and directly addresses use-vs-alternative selection.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/daisydaines/fieldwork-mcp'

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