Exit Ticket Teacher Jobs

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so safety is covered; the description goes further by disclosing the 3-listing threshold, that only names and counts are returned (no titles, pay or links), and the provenance/refresh model with a per-result data_updated_at. What is missing is any statement about result size, ordering, or whether the list is capped.

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 paragraph that front-loads the resource and filter before the field-level and freshness details. The page title is repeated in slightly redundant form (the name plus the URL), but every other clause carries 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?

With no input parameters and no output schema, the description must carry the return-value burden itself, and it does: it states exactly which fields come back and which do not, plus the freshness indicator. Nothing an agent needs in order to call this correctly is absent.

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 no parameters, so the baseline is 4. The description correctly implies there is nothing to configure and instead spends its words on scope and return shape, which is the right allocation for a zero-argument tool.

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 the specific resource (employers from Exit Ticket's 'Companies hiring former teachers' board), the inclusion filter (3 or more open listings), and the returned fields (names and counts). It is immediately clear what the tool yields, though it never explicitly contrasts itself with the sibling employer_counts, which an agent might reasonably confuse it with.

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?

There is no when-to-use or when-not-to-use guidance, and no mention of the alternatives (employer_counts, search_jobs) that overlap with this data. The agent must infer that this is a fixed, no-parameter snapshot rather than a filtered query.

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 readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds genuinely new context beyond that: data is re-scraped from employers' own career sites (Workday, Greenhouse, Lever, Ashby) when the board is rebuilt, and each result carries data_updated_at so the agent can judge staleness. It does not state refresh cadence or rate limits, but the freshness signal is a meaningful addition.

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?

Two compact sentences, front-loaded with what the tool returns before the state qualifier and the output-scope constraint. The domain URL and source-platform list earn their place by anchoring the data provenance, though the sentence runs long and could be split.

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, and the description compensates by naming the returned fields (employer names, listing counts, data_updated_at) and explicitly excluding titles, pay and links. What remains missing is disambiguation from the similarly named sibling, which matters for an agent choosing among five job-board tools.

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 description coverage is 100%, and the schema's state property already explains accepted formats (2-letter code or full name, any case) and the remote-listing matching rule. The description only restates that the state scope is optional, adding no syntax or semantics beyond the schema, so the baseline of 3 applies.

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 concrete verb and resource: it returns employers with open listings for former teachers plus per-employer counts, optionally scoped to one US state. It also draws a clear output boundary ('Names and counts only: no titles, pay or links to listings'). It does not, however, distinguish itself from the near-identical sibling companies_hiring_former_teachers, which leaves an agent guessing between the two.

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: 'optionally for one US state' tells the agent the state filter is optional, and 'no titles, pay or links' hints that search_jobs is the tool for listing detail. There is no explicit when-to-use statement, no exclusion naming a sibling, and no guidance on choosing between this and companies_hiring_former_teachers.

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 establish this is a safe, idempotent, read-only call, and the description adds genuinely useful context beyond them: data is re-read from employers' own career sites (Workday, Greenhouse, Lever, Ashby) on rebuild, and results carry data_updated_at for freshness. It stops short of saying whether calling the tool itself is free or rate-limited, which would have completed the picture.

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 is front-loaded and the parenthetical enumerations are dense but each item is informative rather than filler. It is one long sentence, which makes it slightly hard to scan, but nothing is redundant.

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 and no parameters, the description carries the job of describing the payload, and it does so thoroughly, including provenance and freshness. The only gap is operational context about the call itself (cost/quota), which is minor for a zero-argument info tool.

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 the baseline applies and there is nothing for the description to disambiguate. No misleading or spurious parameter information is present.

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 the resource precisely and enumerates exactly what the call returns: board description, data provenance, totals (listings, employers, remote, hybrid, paid listings, preview size), free vs. plan features, prices and refund rule, and links to docs/MCP/OpenAPI. This is clearly separable from siblings like search_jobs or employer_counts, which return data rather than board metadata.

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 by the content ('About' metadata, totals, pricing) — there is no explicit statement such as 'call this first to understand limits and pricing before searching' nor any exclusion pointing to a sibling. An agent can infer the intent, but the routing guidance is left to inference.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavior: results are counts only, sourced from the board's current data file, refreshed from employer career sites (Workday, Greenhouse, Lever, Ashby) only on rebuild, and each result exposes data_updated_at — which tells the agent how to reason about staleness.

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?

Dense but front-loaded: the primary action and the returned counts come first, provenance and freshness last. The third sentence is somewhat run-on and carries a site URL that adds little for an agent, keeping it just short of a 5.

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 burden of explaining returns, and it does name every field shape an agent would get back, including data_updated_at. It stops short of stating ordering or whether the response is a flat list versus grouped by work mode, which leaves a small gap for a results-interpretation tool.

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 convey and the baseline of 4 applies. The description correctly implies the call is argument-free by describing a global aggregate.

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 plus resource ("List the kinds of work on Exit Ticket") and enumerates exactly what each entry carries: listing counts, fully-remote counts, and counts by work mode. It is clearly distinguishable from siblings like search_jobs or employer_counts, though it never names an alternative to reinforce that separation.

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 aggregate-overview tool rather than a per-job lookup, but there is no explicit "use this when X, use search_jobs when Y" routing. No prerequisites, no exclusions, no mention of when the data is stale enough to distrust.

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 establish a safe, idempotent, closed-world read, so the description's job is to add context, and it does: it discloses the exact return composition (total_matching, free_preview_matching, locked_matching plus full free-preview listings), the paywall behavior (locked listings are counted only; a site plan reveals employer, pay and apply link), and data provenance and freshness (re-read from Workday, Greenhouse, Lever, Ashby; data_updated_at per result). That is materially more than the annotations provide and prevents wrong expectations about coverage.

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?

It is a single dense paragraph, front-loaded with the purpose before the return-behavior detail, and almost every clause carries information the agent cannot get elsewhere. The URL and the enumeration of ATS sources are slightly gratuitous but cheap. Minor tightening would make it a 5.

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 must carry the return shape, and it does precisely: counts, which listings come back in full, which field-level attributes are included, what is withheld behind the paywall, and the freshness field. Combined with full schema coverage on all four optional parameters, an agent has everything needed to call this correctly and interpret the result.

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 description coverage is 100%, so the enum values for role, the 1-20 limit bound, the state code/name matching rule, and the remote_only default are all already documented in the schema. The description only restates the three filter axes at a high level ('kind of work, US state and fully remote') and adds no syntax or edge-case detail beyond the schema. Baseline 3 is appropriate.

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 opens with a specific verb and resource plus the intended audience and source site: 'Search remote and non-classroom jobs for teachers leaving the classroom on Exit Ticket'. That is far more informative than the title alone. It never names a sibling tool (companies_hiring_former_teachers, employer_counts, list_roles), so an agent must infer the boundary rather than being routed explicitly.

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 filter set ('Filter by kind of work, US state and fully remote'), which tells the agent what this tool is for but not when to prefer it over the sibling tools. There are no stated exclusions, prerequisites, or alternative-tool guidance. A one-line routing note would lift this considerably.

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