Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

apple_jobs_locations

Discover valid Apple Jobs location IDs for the location filter: omit q for the full country-level list, or supply q to look up state, metro, or city values.

Instructions

Apple Jobs location discovery. Discovery endpoint for apple-jobs-search's location parameter, whose accepted values are a closed set Apple itself defines (its own <slug>-<CODE> location ids -- free-text location names are rejected). Apple exposes no bulk "list everything" option for this; the only lookup is a fuzzy search capped at 10 results per call covering four granularities (country, state/province, metro area, city) with no empty-input listing mode. With no q, this returns the full country-level value space (206 values, live-verified) as a static list -- the granularity apple-jobs-search's own examples use and nearly every caller needs. With q supplied, this instead looks up Apple's own location filter live so callers can discover state/metro/city-level values for finer filtering; results at those deeper levels may include more than one candidate and are ranked by Apple's own relevance, not alphabetically.

Input Schema

NameRequiredDescriptionDefault
qNoOptional free-text location search. Omit to get the full country-level list; supply to live-search state/metro/city-level values too (e.g. a city name).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.5

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so richly: closed value set, free-text rejection, no bulk 'list everything' option, no empty-input listing mode, a 10-result cap, four granularities, live-verified 206 country values, and non-alphabetical relevance ranking. This is unusually complete behavioral disclosure for a discovery endpoint.

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

Conciseness4/5

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

Purpose and the fed-parameter relationship are front-loaded, and no sentence is pure filler. It is dense and long for a single optional parameter, but the density is warranted by the closed-set and dual-mode complexity, so it is only marginally over-sized.

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?

Covers what each invocation returns (country-level value space vs live finer-grained candidates) and the constraints on the values. Without an output schema it could say a little more about the shape/fields of the returned list, but the behavioral picture is essentially complete.

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, and the schema description already covers omit-vs-supply. The description adds value beyond it by tying each mode to a granularity level and by disclosing the 10-result cap and Apple-side relevance ordering for deeper lookups.

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?

Names the specific resource (Apple Jobs locations) and its role as a discovery endpoint for apple-jobs-search's `location` parameter. It explicitly identifies the sibling it feeds and the closed value format (`<slug>-<CODE>`), so an agent can distinguish it from search 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.

Usage Guidelines5/5

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

States exactly when to omit `q` (full country-level list, the common case) versus supply it (live state/metro/city lookup), and explains why the tool is necessary at all: apple-jobs-search rejects free-text locations and offers no bulk listing. The alternative and the selecting condition are both explicit.

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

Deploy Server

Other Tools