Fetch a single Amazon.jobs posting using its numeric job ID. Returns parsed JSON from the server-rendered detail page.
Amazon Jobs single posting. Returns one Amazon.jobs posting by its numeric job id (the id field returned by search). Parsed from amazon.jobs's stable server-rendered job detail page — there is no separate JSON detail endpoint upstream.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric Amazon job id |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and reveals that data is parsed from a stable server-rendered page and that no separate JSON endpoint exists. This adds meaningful context about the data source and reliability, though it does not describe error handling or output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, two sentences, with no redundant or extraneous information. It front-loads the core purpose and then gives the key parameter source and technical context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the agent must rely on the description to understand return details. While the description says it returns 'one Amazon.jobs posting', it does not enumerate fields or outline error behavior, leaving some ambiguity for a simple one-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a description for the id parameter, but the tool description adds that it is the field returned by search, giving the agent a clear origin and expected value. This adds value beyond the schema's minimal 'Numeric Amazon job id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns one specific Amazon.jobs posting by numeric job id, using the specific verb 'Returns' and identifying the resource. It distinguishes itself from the sibling search tool by emphasizing 'single posting' and by noting the id comes from search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a workflow by saying the id is 'the `id` field returned by search', which clarifies when to use this tool. However, it does not explicitly name the search sibling tool or state when not to use this tool, leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.