SiteCheck Trade & Energy

ILO Maritime Labour Convention 2006 ratifications from ILO

logistics_maritime_labor_mlc

Read-only

ILO Maritime Labour Convention 2006 (MLC) ratifications from ILO NORMLEX: total ratifications, denunciations, and per country the ratification date, status (In Force / Not in force), declaration text and NORMLEX country link; plus the MLC amendments (2014-2025) with status and entry-into-force dates. Filter by country; other ILO conventions via instrumentId. From normlex.ilo.org via a residential proxy. Related tools on this server, for a different need: logistics_maritime_piracy_alert when you need current piracy and armed-robbery broadcasts from the ICC. Price: $0.01 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "logistics_maritime_labor_mlc"
  }
}

Input Schema

Name	Required	Description	Default
`country`	No	Optional country name filter, e.g. Panama, Liberia, Türkiye
`instrumentId`	No	NORMLEX instrument id (default 312331 = MLC, 2006)

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only say readOnly and openWorld, but the description adds behavior an agent genuinely needs: data origin is normlex.ilo.org fetched through a residential proxy, each successful call costs $0.01 USDC via x402 on Base/Solana/Arc, and failed calls are not charged. That cost and payment-requirement disclosure is decision-critical context not present in any structured field.

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

Conciseness4/5

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

The resource and its payload lead the description, with filtering and pricing trailing in a logical order, and no sentence is filler. It is, however, a long semicolon-chained run-on that would scan faster as separated clauses.

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?

For a two-optional-parameter read tool with an output schema and readOnly/openWorld annotations, everything an agent needs is present: what is returned, how to filter, the default instrument, the source, and the payment terms. No unexplained gaps remain.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: instrumentId is presented as the lever for retrieving conventions other than MLC 2006, which tells the agent the tool is not MLC-specific. The country example is already in the schema, so the added value is modest rather than rich.

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?

States a specific verb+resource pair: it returns ILO Maritime Labour Convention 2006 ratifications from NORMLEX, and enumerates the exact contents (ratification date, status, declaration text, country link, plus 2014-2025 amendments with entry-into-force dates). An agent can tell immediately this is an MLC ratification/status lookup and not a vessel, port, or alert tool.

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?

Gives concrete routing information: use country to filter, and use instrumentId for other ILO conventions, which reframes the tool as a general NORMLEX instrument lookup. It also names a sibling tool, but logistics_maritime_piracy_alert is framed as a different need rather than an alternative for the same need, so there is no true when-not-to-use guidance against overlapping tools.

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

All SiteCheck Trade & Energy tools Inspect

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

Need Help?