jobs-todayLists authorized jobs scheduled for a business day, with bounded customer, schedule, status, and technician fields.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Local business date, YYYY-MM-DD; defaults to today. | |
| limit | No | Maximum number of jobs to return. | |
| status | No | Optional job status filter. | |
| technician_id | No | Optional technician ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, covering the safety profile. The description adds that jobs are 'authorized' and that fields are 'bounded', but does not disclose return format, pagination behavior, or empty-result behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence with no filler. It front-loads the main action and scope, and every qualifier ('authorized', 'business day', 'bounded') earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with four optional parameters, full schema coverage, and safety annotations, the description adequately conveys scope and output field categories. A fully enumerated return schema would be nice, but nothing essential for invoking the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all four parameters, including defaults and constraints, are already fully documented. The description adds only the general 'bounded fields' concept and no per-parameter meaning, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lists' and the resource 'jobs', with a specific scope: 'scheduled for a business day' and 'bounded...fields'. It distinguishes the tool from broader siblings like search-jobs and get-job by implying a narrow, date-scoped view, though it does not name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool for a quick day-scoped jobs lookup, but it gives no explicit when-to-use guidance or exclusions. It does not mention when to prefer search-jobs or get-job instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Tool families are organized by resource and action (get/search/preview/reports), so most tools have a distinct purpose. A few near-overlaps exist—customer-service-requests vs search-service-requests and the many campaign preview/search tools—but descriptions generally clarify boundaries.
The set consistently uses kebab-case with recognizable prefixes like get-, search-, preview-, and reports-, making intent predictable. A few noun-phrase tools (complaint-recall-risk, customer-service-requests, operations-parts, jobs-today) break the verb-first pattern, but they remain readable and grouped.
45 tools is well beyond the 25+ threshold and creates a large surface for agents to navigate, even though the domain is broad. Many tools are narrow read-only variations (e.g., five preview-campaign tools, three reports-* tools), which inflates the count without adding fundamentally new capabilities.
As a read-only/insights server, the surface covers customers, jobs, quotes, invoices, leads, locations, service requests, reviews, campaigns, operations, and reporting with both search and detail access. Minor gaps exist—no get-* for campaign types or social drafts—but these align with the intentionally bounded, safe-read model.