Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

jobs_phenom_board

Search a company's Phenom People job board by domain to find open roles. Filter by keywords, location, or category and paginate with offset and limit.

Instructions

Search a Phenom People tenant's job board. Searches a company's public Phenom People career site (a white-labeled domain such as careers.whataburger.com or jobs.cvshealth.com). domain is the tenant's careers domain from its careers URL. Paged via offset/limit; limit is a best-effort page-size hint some tenants ignore, so count always reflects what actually came back.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoSort order, default relevant
limitNoPage size hint, default 10, max 100 (some tenants ignore this and return their own configured page size regardless)
domainYesPhenom tenant careers domain (careers URL)
offsetNoPage offset, default 0
categoryNoFilter: category contains
keywordsNoFree-text keyword search
locationNoFilter: location contains

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.17.5
    • addedInput schema / properties / sort / enum
      Added value: +[
+  "relevant",
+  "recent"
+]
  2. Addedv1.16.2

TDQS

A3.9/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 disclose a genuinely non-obvious trait: limit is a best-effort page-size hint that some tenants ignore, so count reflects what actually came back. It omits any auth, rate-limit, or output-shape notes, but the pagination caveat is real added value.

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-loaded with the purpose, then domain semantics, then pagination behavior. Every sentence carries information, though the domain explanation is somewhat verbose for what it conveys.

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?

For a 7-param search tool with no output schema, it covers purpose, the required domain, and a key pagination quirk. The filter/sort params are left entirely to the schema, which is acceptable given 100% coverage, but a note on result shape would round it out.

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 adds concrete meaning to domain (white-labeled careers domain from the careers URL) beyond the schema's terse '(careers URL)', but the limit behavior it mentions is already fully spelled out in the schema, leaving most params 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 (Search) and resource (a Phenom People tenant's job board), naming the exact platform. The white-labeled domain examples (careers.whataburger.com, jobs.cvshealth.com) make it immediately distinguishable from the many other jobs_* board tools in the sibling set.

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?

It establishes the context (a company's public Phenom careers site), which implies when to reach for it, but never states when-not or names an alternative. The obvious companion job-detail tool (jobs_phenom_job) is not referenced, so the agent must infer the search-vs-detail split.

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