Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

meta_jobs_search

Search Meta's public careers site by team, technology, location, employment type, ref/req-code keyword, remote-only, or newest-first sort; returns open job requisitions as JSON.

Instructions

Meta Jobs search. Searches Meta's public careers site (metacareers.com) via its own anonymous jobsearch GraphQL endpoint, with the same team/technology/location/employment-type/keyword/remote/sort filters the live search page offers. All filters are optional and combine with AND semantics; an empty request returns Meta's entire open-requisition catalog in one response. q matches team, technology, location, or ref/req-code names -- it is NOT a free-text search over job titles or descriptions. teams enum (org teams + technologies, both use the same field): Advertising Technology, AR/VR, Artificial Intelligence, Business Development & Partnerships, Communications & Public Policy, Creative, Data & Analytics, Data Center, Design & User Experience, Enterprise Engineering, Global Operations, Infrastructure, Internship - Business, Internship - Engineering, Tech & Design, Internship - PhD, Legal, Finance, Facilities & Admin, People & Recruiting, Product Management, Research, Sales & Marketing, Security, Software Engineering, Technical Program Management, University Grad - Business, University Grad - Engineering, Tech & Design, University Grad - PhD & Postdoc, Facebook, Messenger, Instagram, WhatsApp, Meta Quest. roles enum: Full time employment, Internship, Short term employment. results_per_page enum: all, five, ten.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoFacet-name keyword: matches team, technology, location, or ref/req-code -- not a title/description search
rolesNoRepeatable employment-type filter (OR); see roles enum above
teamsNoRepeatable team-or-technology filter (OR); see teams enum above
officesNoRepeatable location-id filter (OR) in Meta's own id format, e.g. menlo-park, london -- not a closed enum
sort_by_newNoSort newest-first instead of relevance
is_remote_onlyNoRestrict to remote-only postings
results_per_pageNoResponse size cap: all, five, ten

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.17.5
    • addedInput schema / properties / offices / items
      Added value: +{
+  "type": "string"
+}
    • addedInput schema / properties / results_per_page / enum
      Added value: +[
+  "all",
+  "five",
+  "ten"
+]
    • addedInput schema / properties / roles / items
      Added value: +{
+  "type": "string"
+}
    • addedInput schema / properties / teams / items
      Added value: +{
+  "type": "string"
+}
  2. Added

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the anonymous endpoint, AND semantics across filters, the behavior of an empty request returning the entire catalog, and the important constraint that q is not a free-text search. It does not mention rate limits or the exact return shape, but the disclosed behavior is substantially more transparent than typical.

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?

The description is long due to the necessary enum lists, but it is well-structured: purpose first, then filter semantics, then q clarification, then enums. Each sentence contributes useful information, and the front-loaded purpose ensures agents immediately understand the tool. It is not overly verbose for the complexity it covers.

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

Completeness3/5

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

Given the tool's complexity (7 optional parameters, multiple enums, no output schema), the description covers the input semantics thoroughly but omits any description of the return value structure. It explains how to query and what filters do, but does not tell the agent whether the response is a list of job summaries, full job details, or includes metadata like total count. This gap matters because there is no output schema to compensate.

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

Parameters5/5

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

Although schema coverage is 100%, the description adds critical meaning beyond the schema: it explains that q matches team, technology, location, or ref/req-code and is NOT free-text; it provides the full teams and roles enums, which the schema merely references as 'see enum above'; and it defines the results_per_page values. This is a substantial addition to the structured parameter definitions.

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 verb and resource: it 'Searches Meta's public careers site (metacareers.com)' via an anonymous GraphQL endpoint. It also lists the supported filter dimensions, making it distinct from the sibling tools like meta_jobs_list and meta_jobs_job, even though those aren't named. The purpose is specific and unambiguous.

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

Usage Guidelines3/5

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

The description explains filter behavior (optional, AND semantics, empty request returns full catalog) and clarifies the q parameter, but it does not explicitly state when to use this tool versus meta_jobs_list or meta_jobs_job. There is implied usage context (searching with filters), but no explicit exclusions or alternative routing, so the guidance is adequate but not complete.

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