Skip to main content
Glama

search_jobs

Search for jobs with filters like titles, locations, companies, skills, salary, and remote options. Returns a list of matching job postings.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number for pagination (default: 1)
limitNoMaximum number of results (default: 5, max: 50). Keep low to avoid large responses.
remoteNoFilter for remote jobs only
skillsNoRequired skills (e.g., ["Python", "React", "AWS"])
titlesNoJob titles to search for (e.g., ["Software Engineer", "Senior Developer"]). Max 6 titles.
companiesNoSpecific companies to search (e.g., ["Google", "Meta", "Apple"])
countriesNoCountry codes to filter (e.g., ["US", "CA", "UK"])
expLevelsNoExperience levels (e.g., ["SE" for Senior, "MI" for Mid-level, "EN" for Entry])
locationsNoLocations to search in (e.g., ["San Francisco", "New York", "Remote"])
dateOffsetNoOnly show jobs posted within this time period (e.g., "2D" for last 2 days)
industriesNoFilter by company industries (use get_industries to see valid values)
companySizeNoFilter by company size (e.g., ["xs" for 1-50, "s" for 50-200, "m" for 200-1K, "l" for 1K-5K, "xl" for 5K+])
baseSalaryMaxNoMaximum base salary (USD)
baseSalaryMinNoMinimum base salary (USD)
h1bSponsorshipNoFilter for jobs offering H1B sponsorship
excludedCompaniesNoCompanies to exclude from results

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations, the description carries the full burden but only states that it 'Returns a list of matching job postings.' It fails to disclose filtering combination logic, default behaviors (e.g., result ordering, limit), potential cost of broad searches, or any side effects. The description adds minimal behavioral context beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core action, and contains no fluff or redundant information. Every word earns its place, and it clearly communicates the primary function and return type.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 16 optional parameters, no annotations, and no output schema. The description only provides a high-level summary and does not explain return format, result ranking, how filters interact, or any limitations. Given the complexity, the description is insufficient for an agent to fully understand the tool's behavior and result structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description lists example filter types ('titles, locations, companies, skills, salary, and remote options') but does not add new meaning beyond what the schema already provides. It accurately summarizes the parameter categories without detailed semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Search for jobs with filters' and specifies the resource (jobs) and the action (search with filters). It is distinct from siblings like get_job and match_jobs, as it explicitly mentions a broad filter-based search and returns a list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when searching for jobs but provides no guidance on when to use this tool versus alternatives like match_jobs or get_job. It doesn't mention exclusions, prerequisites, or scenarios where other tools would be more appropriate.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0
Disambiguation5/5

Each tool targets a distinct resource and action. Tools like get_job vs get_application vs get_job_hunt are clearly separated, and match_jobs vs search_jobs are well-differentiated by saved vs explicit filters. No two tools appear to do the same thing.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_job_hunt, list_applications, update_salary). Even longer names like add_job_to_applications maintain the convention with clear, predictable structure.

Tool Count2/5

With 35 tools, the server exceeds the 25+ threshold that indicates an overly large surface. While the breadth covers a comprehensive job search workflow, the number is likely overwhelming and could be consolidated without losing functionality.

Completeness5/5

The tool set covers the full job hunt lifecycle: creating hunts, searching/matching jobs, applying, tracking applications, managing resumes (including AI-generated versions), outreach, interviews, profile, and compensation. There are no obvious dead ends; update and delete operations are available where needed.

Resources