Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

jobs_oracle_job

Fetch a single Oracle Recruiting requisition by host, site, and requisition ID, returning its full HTML or text description, responsibilities, and qualifications.

Instructions

Get a single Oracle Recruiting (ORC) requisition. Returns a single Oracle Recruiting requisition with its full HTML/text description (description, responsibilities, qualifications). id is the requisition Id from a board listing; host/site as in the board endpoint.

Input Schema

NameRequiredDescriptionDefault
idYesOracle requisition Id from a board listing
hostYesOracle Cloud host (*.oraclecloud.com)
siteYesOracle career site number

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.0

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the return payload (full HTML/text description with description, responsibilities, qualifications), but says nothing about permissions, rate limits, or explicitly confirming this is a safe read-only operation.

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?

Three short sentences, front-loaded with the purpose, then return content, then parameter provenance. No filler, and the most important information comes first.

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 simple detail-lookup tool with no output schema and no annotations, the description covers purpose, return content, and parameter origin adequately. The absence of any safety/permission note is a minor gap, not a blocking one.

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 adds meaning beyond the schema by tying 'id' to a board listing and clarifying that 'host/site' should match the board endpoint, giving the agent the parameter-provenance workflow.

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 and resource: 'Get a single Oracle Recruiting (ORC) requisition.' The word 'single' and the reference to 'a board listing' differentiate it from the board-level sibling (jobs_oracle_board), though the sibling is not named explicitly.

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?

Usage is only implied through the prerequisite hint that 'id is the requisition Id from a board listing' and that host/site match 'the board endpoint', which tells the agent to first call the board tool. There is no explicit when-to-use/when-not statement or named alternative.

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