Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

jobs_icims_board

List an iCIMS tenant's public job board by careers domain, with paging, keyword, and location filters plus full job descriptions inline.

Instructions

List an iCIMS tenant's job board. Lists a company's public iCIMS job board (served through the tenant's white-labeled careers domain, e.g. careers.costco.com — not the bare {company}.icims.com subdomain, which is an OAuth-gated employee portal), paged via page/limit, with the full description inline per job. domain is the tenant's careers domain from its careers URL.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number, default 1
limitNoPage size, default 20, max 50
domainYesiCIMS tenant careers domain (careers URL)
keywordsNoFree-text keyword search
locationNoFilter: location contains

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses pagination via page/limit, that each job includes the full description inline, and that the bare icims.com subdomain is an OAuth-gated employee portal. It omits rate limits/auth expectations for the public board, but the key behavioral constraints are surfaced.

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 and information-dense, with each sentence adding the domain constraint, pagination, or return shape. Minor waste in the near-duplicate opening ('List an iCIMS tenant's job board. Lists a company's public iCIMS job board').

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?

No output schema exists, and the description fills that gap by stating results are paged and include a full description per job. For a 5-param listing tool, this is nearly complete; it could add a note on total counts or keyword/location filter behavior.

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, but the description genuinely adds meaning for the critical 'domain' parameter: it must be the tenant's careers domain from its careers URL and not the {company}.icims.com portal. That disambiguation is not in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('List') and resource ('iCIMS tenant's job board') and explicitly clarifies the resource is the white-labeled careers domain, not the {company}.icims.com portal. It does not name or contrast with the closest sibling, jobs_icims_job, but the board-vs-single-job distinction is inferable from 'board... per 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?

Gives clear selection context: use the tenant's careers domain, not the OAuth-gated subdomain, and notes the full description is inline per job (implying a separate detail call may be unnecessary). No explicit 'use X instead' routing to jobs_icims_job or other boards, so it stops short of a 5.

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