Skip to main content
Glama

Datalastic Vessel Tracking & Maritime Intelligence

by com.datalastic
OverviewDiscussionsAdmin

Check an async report

report_status
Read-only

Check an async report job by report_id (from report_request or report_list). Returns its status: PENDING or IN_PROGRESS (still generating — wait and check again), DONE, or FAILED.

When DONE, result_url is a download link for the result ZIP; hand it to the user. Links are time-limited — if one has expired, run report_status again for a fresh link. The server never downloads the file itself.

FAILED is terminal. Stop polling: it will never become DONE and there will be no result_url. Read the message field and relay it to the user — it is written for a person and explains the cause. Do not resubmit on your own: tell the user what failed and let them decide. If the message points at a parameter the user can correct, offer the corrected submission rather than making it silently.

A report going from IN_PROGRESS back to PENDING is an automatic retry, not a failure. Keep polling.

Failed reports are not charged, and polling is free — it never re-runs the report or deducts credits.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
report_idYesThe report_id returned by report_request (or seen in report_list).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusYes
messageYes
report_idYes
created_atYes
result_urlYes
updated_atYes
report_typeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / message
      Added value: +{
+  "type": [
+    "null",
+    "string"
+  ]
+}
    • changedOutput schema / required
      Previous value: -[
-  "report_id",
-  "report_type",
-  "status",
-  "result_url",
-  "created_at",
-  "updated_at"
-]New value: +[
+  "report_id",
+  "report_type",
+  "status",
+  "message",
+  "result_url",
+  "created_at",
+  "updated_at"
+]
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations provide readOnlyHint=true and destructiveHint=false, but the description adds critical behavioral details: time-limited links requiring a fresh call, the server never downloading the file, terminal FAILED status, automatic retries, and cost implications. These are beyond the annotations and essential for correct agent behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence earns its place, explaining statuses and required actions. It is front-loaded with the core purpose and then layers behavioral nuances logically. There is no fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists (implied by statuses and fields), the description covers all necessary edge cases: polling behavior, expiry, failure handling, cost transparency. An agent has everything needed to invoke and respond correctly without additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single parameter, and the description essentially repeats the schema's meaning ('from report_request or report_list'). Since the schema already documents the parameter well, the description adds minimal new semantic value. Baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool's function: 'Check an async report job by report_id' and enumerates the possible statuses. It names the resource (report) and the action (check), and distinguishes itself from siblings by referencing report_request and report_list as sources of the report_id.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use guidance: 'by report_id (from report_request or report_list)'. It also gives detailed instructions for each status outcome—when to wait, when to hand off a result, when to relay a failure message—and explicitly forbids resubmitting without user consent. This far exceeds typical usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Datalastic Vessel Tracking & Maritime Intelligence toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources