Trade & Logistics Evidence

Container Delay & Free-Time Evidence Monitor

container-exception-evidence

Turn buyer-authorized container event snapshots into deterministic ETA, milestone, free-time, cost-exposure, confidence, limitation, and human-review evidence. No carrier scraping, reference fetching, legal verdict, automatic claim, or provider key. — $0.02/call, x402 (USDC on base).

Input Schema

TableJSON Schema

Name	Required	Description
`mode`	Yes	Use snapshot for customer events or synthetic_demo for the one exact canonical zero-provider public example. The demo accepts only the published fixture values; runtime rejects any changed field, extra row, customer row, or secret before effects.
`events`	Yes	At least one and at most 50,000 events. Snapshot accepts customer events; synthetic_demo accepts exactly the two fixed Actor-owned events in the public fixture and rejects substitutions or extra rows before effects. Safe references are validated but never fetched.
`watchId`	Yes	Stable identifier for one customer-owned monitoring series.
`containers`	Yes	At least one and at most 1,000 closed records. Snapshot accepts customer containers; synthetic_demo accepts exactly one fixed Actor-owned Synthetic Ocean record and rejects substitutions before effects. BOL and booking values are never returned raw.
`sourceStatus`	Yes	Declare whether this customer-supplied snapshot is complete, partial, or unavailable.
`continuationState`	No	Optional exact nextContinuationState from a previous successful complete run. The Actor does not store this state in a named KVS; pass it back to compare the next customer snapshot.
`rightsAttestation`	Yes	Required customer declaration. Apify Input Schema v1 can serialize false here; the Actor runtime requires all three declarations to be exactly true and rejects otherwise before provider, Dataset, billing, state, lock, intent, or delivery effects. Do not submit credentials, secrets, or data you are not authorized to use.
`tariffAssumptions`	Yes	Customer-supplied USD/day assumptions. No terminal calendar or carrier tariff is fetched.

TDQS

A4.2/5.0

Behavior4/5

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

Beyond the sparse annotations, the description discloses meaningful behavioral constraints: no carrier scraping, no reference fetching, no legal verdict, no automatic claim, no provider key required, and a fixed price of $0.02/call. This adds real value, though it does not describe whether output is persisted to a Dataset or how state is handled.

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 three short sentences: purpose, constraints, and pricing. It is front-loaded with the core purpose, and every clause adds distinct information without wasted words.

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?

The tool is complex (nested objects, 8 params, no output schema), but the description covers core purpose, output categories, and key non-goals. The schema's rich per-parameter descriptions fill in most details, though the description could be more explicit about how evidence is returned (e.g., Dataset item or structured payload).

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?

The input schema provides 100% coverage with detailed descriptions for all 8 parameters, so the top-level description does not need to add parameter-level meaning. It lists output categories but not parameter syntax or semantics, which is appropriate given the schema's depth.

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 uses a specific verb ('Turn') and explicitly names the resource ('buyer-authorized container event snapshots') and the outputs ('ETA, milestone, free-time, cost-exposure, confidence, limitation, and human-review evidence'). It clearly distinguishes this from sibling evidence tools by domain (container delay/free-time vs carbon compliance) and states non-goals like 'no legal verdict, automatic claim'.

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

Usage Guidelines4/5

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

The description clearly implies use when the user has buyer-authorized container event snapshots and explicitly rules out use cases that require carrier scraping, reference fetching, or provider keys. However, it does not name a specific alternative tool for those cases, so the guidance is context-rich but not fully explicit about alternatives.

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

All Trade & Logistics Evidence tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation5/5

Each tool targets a distinct logistics evidence domain: container exceptions, Panama Canal, bunker/tanker, Strait of Hormuz, voyage carbon, and pricing metadata. There is no overlap in purpose or resource type, so an agent can easily select the correct tool.

Naming Consistency5/5

All tool names follow the same pattern: lowercase descriptive noun-phrases joined by hyphens (e.g., 'container-exception-evidence', 'panama-canal-queue-transit-imbalance'). The style is uniform and predictable, making the set feel cohesive.

Tool Count5/5

With six tools, the server is well-scoped for a specialized evidence bundle. Each tool provides a distinct service, and pricing_info serves as a necessary meta-tool for onboarding. This is an appropriate size for the stated purpose.

Completeness4/5

The tools cover a diverse range of trade and logistics evidence scenarios, including container events, canal transits, fuel demand, strait flow recovery, and carbon compliance. While there are always possible additions (e.g., customs or general tracking), the current set covers the core evidence needs without obvious dead ends.

Resources

Need Help?