Off the Floor Nurse Jobs

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add context — and it does, disclosing data lineage (re-read from employer career sites when the board is rebuilt) and the presence of a per-result data_updated_at, which is a freshness caveat an agent would otherwise miss. It also flags that the employer page link is conditional ('where there is one').

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?

Front-loaded with the outcome (employers plus counts) and appropriately short for a one-parameter tool, with every sentence carrying scope, output shape, or freshness detail. The parenthetical list of source ATS platforms (Workday, Greenhouse, Lever, Ashby) and the inline URL are marginally expendable.

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?

With no output schema, the description correctly takes on the return-shape burden, naming the fields returned (employer name, count, optional page link, data_updated_at). Ordering of results and any result-count caps are unstated, which is a minor gap for an aggregation endpoint.

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% and the single state parameter is fully documented there, including match semantics for remote listings. The description adds only the constraint that it is 'for one US state' (singular), which is a marginal addition over the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

States a specific verb and resource (employer names with open nurse-job counts on Off the Floor) and bounds the scope to an optional single US state. The negative scoping sentence — 'Names and counts only: no titles, pay or links to listings' — tells an agent how this differs from a listing-level tool like search_jobs without needing to open a schema.

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?

Usage is only implied: the aggregate-by-employer framing plus the optional state filter suggests when this is the right call, and the 'no titles, pay or links' note hints it is not a substitute for a job search. But no sibling tool is named, and there is no explicit when-to-use/when-not guidance or statement of prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this a safe, idempotent read with no open-world access, so the safety profile is covered. The description does add genuine behavioral context beyond that: data is re-read from employers' own career sites (Workday, Greenhouse, Lever, Ashby) when the board is rebuilt, and each result carries data_updated_at. It stops short of saying whether counts or prices can lag or when the board was last rebuilt.

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?

The resource and source URL are front-loaded, and the enumerated contents are dense but each item is a distinct thing an agent might need. The middle list is long enough to read as a catalogue rather than prose, and the second sentence about data provenance could have been merged more cleanly.

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?

There is no output schema, so the description carries the burden of describing return content, and it does so by enumerating totals, plan features, pricing, links, and data_updated_at. For a zero-parameter informational tool this is nearly complete; only the shape of the totals object and the link fields is left unspecified.

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?

The tool takes zero parameters, so there is no parameter meaning to add and the baseline of 4 applies. Schema coverage is 100% with an empty object, leaving nothing undocumented.

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 names a specific resource (metadata about the Off the Floor job board) and enumerates its contents: origin of data, totals, free-vs-plan features, prices, refund rule, and doc/MCP/OpenAPI links. It is clearly not a search or listing tool like the siblings. A minor ambiguity remains because 'totals (listings, employers, remote, hybrid...)' overlaps with the sibling employer_counts, and the description does not say which one to prefer for counts.

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?

Usage is only implied: an agent can infer this is the tool to call for orientation, pricing, or documentation links. There is no explicit when-to-use statement and no exclusion naming employer_counts or search_jobs as the alternative for specific data lookups.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this as read-only, idempotent, non-destructive, and closed-world. The description adds useful behavioral context: it returns counts only, reads from the board's current data file, refreshes from employer career sites when the board is rebuilt, and reports data_updated_at.

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?

The description is front-loaded with the core output, then clarifies that it returns counts only, then adds data freshness context. The three sentences are compact and each contributes useful information.

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 no-parameter, read-only aggregate tool with no output schema, the description explains the categories of counts returned and the data freshness marker. Nothing material is missing for correct invocation.

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?

There are zero input parameters, so parameter semantics carry no burden and the baseline is 4. The description does not need to explain parameter meanings because no parameters exist.

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 uses a specific verb and resource: listing role families with listing counts, remote counts, license counts, and work-mode counts. It is clear what the tool returns, though it does not explicitly distinguish itself from the sibling employer_counts or search_jobs tools.

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 phrase "Counts only" implies this is for aggregate reporting rather than detailed job lookup, which helps distinguish it from search_jobs. However, it gives no explicit when-to-use guidance or named alternatives, so the agent must infer the routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations by disclosing the gating behavior: only free preview listings come back in full, everything else is counted only and requires a site plan to see employer, pay and apply link. It also explains data provenance and freshness ('re-read from employers' own career sites... each result gives data_updated_at'), which tells the agent not to treat results as live postings. Annotations already cover read-only/idempotent safety, so this added behavior is the valuable part.

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?

Front-loaded with the action and source, then the filters, then the return shape and caveats in a logical order. It is dense but every sentence carries information; only minor trimming would improve it.

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?

With no output schema, the description carries the return-value burden and does so: it names the three count fields, enumerates the fields of each full listing, and explains the locked-listing gap and data_updated_at. Combined with the thorough input schema, an agent has everything needed to call this correctly and interpret the response.

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 the schema already documents every parameter including enum meanings, default limit and the state matching rule. The description adds a little gloss on what the filters mean but mostly restates what the schema carries; the one genuinely additive note (counts cover every match) is already in the limit description.

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?

States a specific verb and resource ('Search remote, hybrid and non-bedside nurse jobs on Off the Floor') and enumerates the filter dimensions, so the agent knows exactly what the tool retrieves. It does not explicitly distinguish itself from siblings like employer_counts or job_board_info, whose territory (counts, board metadata) overlaps somewhat with the counts this tool also returns.

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?

Usage is implied by the framing (find nurse job listings, filter by role/state/remote/license), but there is no explicit statement of when to prefer this over employer_counts or job_board_info, nor any prerequisites or exclusions. An agent can infer the right context but is not guided to the alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.