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?
Annotations already declare readOnlyHint=true, and the description reinforces this with 'Retrieves'. It adds context about the job state (completed) and explicitly disclaims future capabilities (durable queued jobs, downloadable links). No contradiction with annotations.
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: the first fronts the core purpose and the second adds a relevant limitation. No filler, every word earns its place.
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?
For a simple retrieval tool with 2 parameters, the description covers the primary use, input source, and contract limitations. Although there is no output schema and the return format is not described, this is not critical for a by-ID lookup, and the input schema is fully self-explanatory.
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?
Schema coverage is 100%, with both job_id and request_id documented directly in the schema. The description adds only that job_id is returned by create_geometry_export or create_conversion_job, which slightly enriches the schema but does not add significant new meaning given the schema already explains the parameter.
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 'Retrieves a completed bounded v0 geometry export or conversion job by job_id' – a specific verb, resource, and identifier. It distinguishes itself from sibling creation tools like create_geometry_export and create_conversion_job by focusing on retrieval.
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?
It explains that the current contract only supports completed inline jobs, and that durable queued jobs and downloadable artifact links are future capabilities. This implicitly tells users when not to expect those features, and the job_id reference ties it to the creation workflow. It doesn't explicitly name alternatives, but the boundary is clear.
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: point resolution, reference conversion, hierarchy traversal, geometry retrieval, export creation, job estimation, catalog discovery, and relationship comparison are all separated. The descriptions explicitly state what each tool does and what it does not do, preventing misselection. Even closely related tools like get_geometry, get_geometry_export, and estimate_geometry_package are differentiated by their roles (single-shape retrieval vs. export artifact vs. dry-run estimate).
All 20 tool names follow a consistent verb_noun snake_case pattern (e.g., get_geometry, create_conversion_job, resolve_point, list_reference_systems). The verbs are action-oriented (get, create, estimate, resolve, compare, list, read) and each noun clearly indicates the subject. While a few like 'loc_id_info' and 'how_geometry_works' deviate slightly from the strict verb_noun structure, they still fit the overall style and are easy to predict.
The 20 tools are slightly above the typical 3-15 range but still well-scoped for a comprehensive geocoding and geography service. The extra tools reflect the breadth of operations offered (discovery, conversion, estimation, export, resolution, relationship analysis), each earning its place. The count feels reasonable given the domain, though it approaches the upper boundary of what an agent might easily navigate.
The tool surface covers the full lifecycle of geocoding workflows: discovery (get_catalog, get_pack, read_geometry_catalog), point resolution (resolve_point), reference resolution (resolve_reference), identifier identification (identify_reference_system), hierarchy traversal (resolve_loc_id_scope, loc_id_info), geometry retrieval (get_geometry), relationship analysis (compare_geographies), conversion (convert_reference, create_conversion_job), export (create_geometry_export), and estimation (estimate_geometry_package, estimate_conversion_job). The inclusion of help tools (get_tool_help, how_geometry_works) and job status retrieval ensures no dead ends. The absence of destructive or update operations is consistent with a read-only geospatial data service, so the surface is appropriate.