Snapshot of the verified pool: how many jobs are live right now, counts by work mode, and the occupations (role slugs) with jobs today. Good first call to see what's available before searching.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the tool is a snapshot (read-only, non-destructive) and lists the specific data returned: counts, counts by work mode, and occupations. This is sufficient transparency for a simple aggregation tool, though it could mention any limitations or performance characteristics.
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 two sentences, efficiently front-loaded with the core purpose. Every word adds value, with no redundancies or filler.
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?
Given the absence of an output schema, the description adequately explains the return value's content: counts, counts by work mode, and occupations. It omits structural details but for a simple snapshot, this is sufficient for correct use.
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 has zero parameters, and the schema coverage is 100% (empty object). The description correctly adds no parameter details because none exist. For a parameterless tool, the baseline of 4 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 clearly states it provides a snapshot of the verified pool, including counts of live jobs, counts by work mode, and occupations with jobs today. It distinguishes itself from sibling tools (get_verified_job and search_verified_jobs) by being an aggregate overview.
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 explicitly says 'Good first call to see what's available before searching,' providing clear context for when to use it. It implicitly suggests that for searching, one should use search_verified_jobs, though it doesn't explicitly state 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.
Add one secure layer between your agents and this server.
Each tool serves a distinct purpose: get_jobs_overview provides summary counts, search_verified_jobs returns filtered lists, and get_verified_job retrieves full details by ID. There is no functional overlap.
All tool names follow a consistent verb_noun pattern using snake_case (get_, search_), making them predictable and easy to understand.
With only 3 tools, the server is minimally scoped but covers the essential operations for verified job data access. The count is appropriate for a focused read-only service.
The tool set covers the full read lifecycle: overview, search, and detail retrieval. No write operations are needed for this domain, so there are no obvious gaps.
