Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

tes_job_search

Search Tes teaching jobs by keyword, location, radius, salary, contract type/term, position, subject, or workplace, and get listing details plus live faceted counts.

Instructions

Search Tes teaching jobs. Searches Tes's (tes.com) teaching-jobs board. Returns listing facts (title, employer, location, salary, contract terms/types) plus a short excerpt of the listing description, not the full long-form job-description copy, and the same live faceted-search breakdown (position/subject/workplace category trees with counts, plus contract type/term counts) the real search page renders as its filter sidebar. location is a free-text place name (a UK town/city, an international city, or a bare country name) resolved to coordinates; omit for Tes's own default market, "United Kingdom". radius_miles selects the search radius around location. contract_type and contract_term are validated against Tes's own small, closed label sets. position, subject, and workplace are comma-separated filters -- Tes's own category labels are numerous and can change, so read a prior response's own facets.positions[].value (and facets.positions[].children[].value)/facets.subjects[].value/facets.workplaces[].children[].value for the live, current set rather than guessing. salary_min filters to jobs with an advertised salary at or above that amount (in the searched market's local currency); Tes's own filter panel offers only a minimum, no maximum.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoOne-based page
sortNoSort order
subjectNoComma-separated subject label(s) -- see the endpoint markdown
keywordsNoJob title or keyword
locationNoFree-text place name resolved via Tes's own location autocomplete
positionNoComma-separated position category label(s) -- see the endpoint markdown
page_sizeNoResults per page
workplaceNoComma-separated workplace/organisation-type label(s) -- see the endpoint markdown
salary_minNoMinimum advertised salary, in the searched market's local currency
radius_milesNoSearch radius around location, in miles
contract_termNoContract term
contract_typeNoContract type

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.17.5
    • addedInput schema / properties / contract_term / enum
      Added value: +[
+  "Permanent",
+  "Fixed Term",
+  "Casual",
+  "Maternity Cover",
+  "Temporary",
+  "Supply"
+]
    • addedInput schema / properties / contract_type / enum
      Added value: +[
+  "Full Time",
+  "Part Time"
+]
    • addedInput schema / properties / radius_miles / enum
      Added value: +[
+  3,
+  5,
+  10,
+  15,
+  20,
+  30,
+  50,
+  70,
+  100,
+  500
+]
    • addedInput schema / properties / sort / enum
      Added value: +[
+  "relevance",
+  "newest",
+  "distance"
+]
  2. Addedv1.16.2

TDQS

A4.5/5.0
Behavior4/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 substantial work: it discloses the return shape (listing facts plus a short excerpt, not full description copy, plus the live facet breakdown), that location is resolved to coordinates, and that contract_type/contract_term are validated against Tes's closed label sets. It does not explicitly state read-only/side-effect safety or pagination behavior.

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?

Front-loads the core purpose and is dense with non-redundant detail; almost every clause earns its place. It is delivered as one long paragraph, which is harder to scan than a segmented form, but the length is largely justified for a 12-parameter tool.

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

Completeness5/5

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

There is no output schema, so the description must explain returns, and it does thoroughly (listing facts, excerpt vs. full copy, and the faceted sidebar breakdown). Combined with the parameter guidance and default-market behavior, an agent has everything needed to call it correctly.

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?

Schema coverage is 100% and schema descriptions are terse ("see the endpoint markdown"), yet the description adds heavy meaning beyond them: location semantics and default market, radius_miles purpose, comma-separated nature and authoritative facet source for position/subject/workplace, salary_min currency and no-maximum constraint, and closed label sets for contract fields.

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+resource+source ("Search Tes teaching jobs... Searches Tes's (tes.com) teaching-jobs board") and bounds it to one board, distinguishing it from other job tools like google_jobs or indeed_search. The scope is precise enough that an agent knows what it returns without opening the schema.

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?

Gives clear usage context: omit location for Tes's default UK market, salary_min is local-currency and has no maximum, and position/subject/workplace should be sourced from a prior response's own facets rather than guessed. It does not, however, name sibling tools (e.g., tes_job_detail) or state when this search is preferable to them.

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