Search open jobs in grid, nuclear, renewables, storage and data centers. Read-only, no login.
Scored across 3 tools
Each tool has a single clear role: list_sectors supplies filter vocabularies, search_jobs finds postings, and get_job fetches one listing by slug/URL. The descriptions explicitly cross-reference each other and state what each tool is NOT for, eliminating overlap.
All three tools follow a consistent verb_noun snake_case pattern (get_job, list_sectors, search_jobs). Verbs are standard and predictable for a read-only data API.
Three tools is on the thin side but each maps to a distinct step of the job-search workflow, so nothing feels redundant. A slightly larger surface (e.g. dedicated pagination or employer lookup) could be justified but is not required.
The discover-search-detail lifecycle is fully covered, including taxonomy lookup for valid filter values and a graceful message for closed jobs. Applying is handled via external links, which is a reasonable scope boundary rather than a gap.
Use this when the user wants the details of one job found with search_jobs: pay, location, job type, and the employer description. Takes the job slug or the full job URL. Returns facts, the employer-written text, and the link to read the full listing and apply. Not for searching. A job that closed returns a message saying so.
| Name | Required | Description | Default |
|---|---|---|---|
| job | Yes | Job slug from search_jobs, or the full nextgenenergyjobs.com job URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety burden is light; the description still adds real value by describing the return content (facts, employer-written text, a link to read and apply) and the closed-job edge case that returns a message instead of details. It stops short of saying what happens with an invalid/malformed slug or URL, which keeps it at 4 rather than 5.
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?
Five short sentences, front-loaded with the trigger condition, then inputs, then returns, then the exclusion, then the edge case. Nothing is redundant and each sentence carries distinct 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 output schema, the description correctly takes on the job of describing what comes back and covers the closed-posting case, which is the main surprising behavior. Minor gaps remain around error handling for unparseable input and whether the apply link is always present.
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 parameter already documents that it accepts a job slug from search_jobs or a full nextgenenergyjobs.com URL. The description repeats that contract without adding format, normalization, or error semantics, so baseline 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?
States a specific verb and resource (get details of one job) and enumerates the fields returned: pay, location, job type, employer description. It explicitly separates itself from search_jobs with 'Not for searching', so an agent can pick between the two siblings without opening 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?
'Use this when the user wants the details of one job found with search_jobs' gives the precondition (the job must first be found), and 'Not for searching' states the exclusion. The alternative is named and the selector condition is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when you need the valid sector, seniority, job type and posted-date values for search_jobs, or the user asks what kinds of energy jobs exist. Returns the four sectors with a short scope and live open-job counts. Cheap to call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 bar is lower. The description adds genuine extra context — that output includes live counts and that the call is cheap — which helps an agent decide to call it proactively. No auth or rate-limit detail, but none is needed here.
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 sentences, front-loaded with the when-to-use condition, followed by the return shape and a cost hint. Every clause carries information; nothing is padding.
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 zero-parameter, read-only lookup with no output schema, the description covers the three things an agent needs: when to call it, what it returns, and that it is inexpensive. Nothing material 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?
The tool takes zero parameters, so per the baseline this scores 4; the empty schema matches the description's implicit claim that no arguments are needed. Nothing in the description contradicts or complicates the empty input contract.
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 ('list_sectors' → the valid sector, seniority, job type and posted-date values) and explicitly ties it to search_jobs, so it is clearly distinguishable from get_job and search_jobs. The return content (four sectors with scope and live open-job counts) is named up front.
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?
Gives two explicit triggering conditions: needing valid filter values for search_jobs, or a user asking what kinds of energy jobs exist. It names the sibling it feeds, so the agent knows this is a lookup step before search_jobs rather than a replacement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants to find open jobs in the modern power sector: grid, nuclear, renewables, data-center power. Searches active postings on nextgenenergyjobs.com by keyword, employer, location, sector, seniority, job type, remote and posted date. Battery storage has no sector of its own: search it with query. Returns 10 jobs per page, newest first (by the date the job was first seen), with a link and a slug for get_job. Pay shows when the listing has pay data; estimates are labeled. Not for jobs outside energy, resume writing or applying.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, 10 jobs per page. | |
| query | No | Keywords, e.g. "electrical engineer" or "battery storage". Skip for browse-only searches. | |
| remote | No | true = jobs flagged remote in the listing. | |
| sector | No | Sector slug. Call list_sectors for what each one covers. | |
| company | No | Employer name, e.g. "Fervo Energy". An unknown name returns 0 jobs and similar names. Wins over sector when both are set. | |
| location | No | One city, US state, or country, e.g. "Texas" or "Denver, CO". For a metro area use its main city (Bay Area -> San Francisco) or the state. No zip codes. Spell out non-US regions (Ontario, Canada). | |
| with_salary | No | true = only jobs with pay data. Estimated pay is included and labeled "estimate". | |
| posted_within | No | Only jobs posted within the last 24 hours, 7, 30 or 90 days. | |
| employment_type | No | ||
| experience_level | No |
| Name | Required | Description |
|---|---|---|
| jobs | Yes | |
| page | Yes | |
| total | Yes | |
| totalPages | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world, so safety is covered. The description still adds real behavioral context: 10 results per page, newest-first ordering defined by first-seen date, pay shown only when present and estimates explicitly labeled — none of which is derivable from annotations or schema.
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 use case, then coverage, then the special-case caveat, then return shape, then exclusions — a sensible order with no filler sentences. It is dense and long for a single block; a short line break before the exclusion sentence would improve scanability without cutting content.
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?
An output schema exists, so return values need not be explained, yet the description still gives page size, ordering, and pay-data caveats. Combined with the sector/query workaround and clear exclusions, an agent has everything needed to call this correctly with 10 optional parameters.
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 80%, so the baseline is 3 and the schema already documents each parameter well. The description adds meaning the schema lacks: that 'battery storage' must be expressed through query rather than sector, and that results carry a slug usable with get_job. It does not restate enum or format rules, which 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?
Opens with a specific verb and resource plus a domain boundary ('find open jobs in the modern power sector: grid, nuclear, renewables, data-center power') and names the source site. An agent can immediately distinguish this from get_job (single posting) and list_sectors (sector reference).
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?
Explicit trigger ('Use this when the user wants to find open jobs'), explicit exclusions ('Not for jobs outside energy, resume writing or applying'), and concrete routing rules for edge cases (battery storage has no sector, so use query; slugs feed get_job). This is close to ideal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_joblist_sectorssearch_jobsSearch open defensive cybersecurity (blue team) jobs and salary data. Read-only, no sign-in.
Search ~1.4M open jobs from 24k company career boards: Greenhouse, Lever, Ashby, Workday and more
Search live jobs, read postings, and look up how employers hire and pay. Free, no sign-in.
Search current job postings from companies' own career sites. Free, no account.
Add one secure layer between your agents and this server.