Skip to main content
Glama

search_indeed

Find Canadian job postings on Indeed by title, location, and radius, returning salary bands and listings for follow-up full-text retrieval.

Instructions

Search ca.indeed.com. Carries salary bands on most result cards, and get_indeed_job will read the full body of any result — including postings a UKG or PeopleSoft careers site will not serve. Returns one page (~15 postings) per query: every deeper offset returns Indeed's sign-in wall, so refining the query changes which postings appear rather than how many.

Input Schema

NameRequiredDescriptionDefault
limitNoJobs to return (default: 25)
titleNoJob title or keywords, e.g. "administrative assistant"
locationNoCity, e.g. "St. Catharines, ON"
radius_kmNoSearch radius in km (0 = Indeed's default 25)
strict_titleNoRequire the title words in the posting's own title
strict_locationNoRequire the posting's own city to match; off by default since Indeed searches a radius

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.8.6

TDQS

A4.6/5.0
Behavior5/5

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

No annotations exist, and the description carries the full burden well: it discloses the ~15-posting page cap, the sign-in wall on deeper offsets, that salary bands appear on most cards, and that some postings are reachable here that UKG/PeopleSoft career sites will not serve. These are exactly the operational traits an agent cannot infer from 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?

Three tight sentences, front-loaded with what is searched, followed by result quality, the follow-up tool, and the pagination caveat. No sentence is filler and the most consequential constraint (no deep pagination) is stated plainly.

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

Completeness4/5

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

With no output schema and no annotations, the description supplies result count, salary-band richness, and the escalation path to get_indeed_job, which is nearly everything needed. What remains unstated is the shape of returned fields and whether empty result sets or blocked offsets surface as errors versus empty lists.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description earns a bump by clarifying that the effective result ceiling is one page (~15) per query, which tempers expectations for the limit parameter (max 100, default 25). It says nothing about title, location, radius_km, or the strict_* flags, leaving those entirely to the schema.

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?

States a specific verb and named resource with geographic scope ("Search ca.indeed.com"), which immediately separates it from search_linkedin_jobs, search_jobbank and the other board-specific searchers. It also distinguishes itself from get_indeed_job by assigning that sibling the full-body reading job.

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

Usage Guidelines4/5

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

Explicitly routes the agent to get_indeed_job for full posting bodies and warns that deeper offsets hit a sign-in wall, so the correct behavior is to refine the query instead of paginating. It gives no guidance on choosing between this and the other job-board siblings when a title matches several, which is the only gap.

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