get_job_statusRetrieves a completed bounded v0 geometry export or conversion job by job_id. The current public contract creates completed inline jobs only; durable queued jobs and downloadable artifact links remain a future Custom Data Builder capability.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Job id returned by create_geometry_export or create_conversion_job. | |
| request_id | No | Optional caller-supplied request id for tracing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The read-only annotation is complemented by the description's clarification that only completed inline jobs are retrievable, and that queued jobs or artifact links are not yet available. This adds practical expectations for callers.
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?
Two sentences deliver purpose and limitations clearly, with no wasted words. The first sentence is immediately actionable, and the second provides necessary context without bloat.
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?
Although no output schema exists, the description is sufficient for a simple retrieval operation, covering what is retrieved and noting what is not available. It does not describe the response structure or error behavior, but these are less critical given the tool's simplicity.
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 fully describes both job_id and request_id, so the description adds no new parameter semantics. It only restates job_id as a lookup key, which is redundant with the schema's 100% coverage.
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's action: retrieving a completed geometry export or conversion job by job_id. Its focus on job retrieval distinguishes it from sibling tools that create runs or estimate packages. The phrase 'completed bounded v0' adds precise scope.
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 this tool is for fetching jobs after creation, with a note that only inline completed jobs are supported under the current contract. It does not explicitly say 'use this after create_geometry_export' or list when not to use it, leaving the guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: discovery (get_catalog, get_pack), geometry retrieval (get_geometry), hierarchy (loc_id_info, resolve_loc_id_scope), relationship analysis (compare_geographies), preflight (check_geometry), export estimation and creation (estimate_geometry_package, create_geometry_export), job status (get_job_status), and help (get_tool_help). Even closely related tools like check_geometry and estimate_geometry_package address different concerns (shape availability vs export artifact), leaving no ambiguity.
Most tools follow a consistent verb_noun pattern (check_geometry, compare_geographies, create_geometry_export, estimate_geometry_package, get_catalog, get_geometry, get_job_status, get_pack, get_tool_help, resolve_loc_id_scope). However, 'loc_id_info' breaks the pattern by being a noun phrase rather than a verb action, causing a minor deviation from the otherwise uniform convention.
With 11 tools, the server covers the key operations for administrative boundary data—discovery, geometry retrieval, hierarchy navigation, comparison, export, and job management—without overreach. Each tool is necessary for a coherent workflow, and the count fits well within the typical 3-15 range for a domain-specific MCP server.
The tool set effectively covers the full lifecycle needed for administrative boundary use: discovery (catalog/pack), preflight checks, geometry retrieval, hierarchical navigation, relationship analysis, export estimation/creation, and job status. It includes essential utilities like get_tool_help for onboarding. No obvious gaps exist for the server's purpose; if anything, it is notably thorough for read/export operations.