Skip to content

feat(mcp): list tools default to actively tracked records and dashboard definitions - #404

Closed
alosec wants to merge 4 commits into
mcp-previewfrom
feat/mcp-tracked-default
Closed

alosec wants to merge 4 commits into
mcp-previewfrom
feat/mcp-tracked-default

Conversation

@alosec

@alosec alosec commented Oct 7, 2026 •

Copy link
Copy Markdown
Contributor

Part 1 of the #398 split. Base mcp-preview (Akshay's verified filters, #397).

What changes

list_containers and list_shipments add actively_tracked: true unless the caller sets actively_tracked / tracking_stopped or passes include_stopped_tracking: true (for history such as past pickups or dwell). The tool descriptions carry the dashboard's definitions and ask for the set's total first:

  • ready for pickup = current_status: available
  • at risk of demurrage = requires_attention: true, sort attention_priority (the Containers at Risk view)
  • discharged but not picked up = available,not_available,grounded,awaiting_inland_transfer

No Rails change: both filters already exist. The dashboard applies the tracked filter on every worklist; the MCP didn't.

Evidence (one change, one measurement)

Starter chips on staging Sodor, 5 chips × 3 runs, Braintrust project AskT49:

Arm Mean grade
Akshay's filters only (starter-chips-v1-filters-20261006) 0.47
+ this PR (starter-chips-v1-tracked-default-20261006) 0.87

The arm-C run is exactly this commit (no compact rows, no summarize). Totals before and after on the same question:

Chip Filters only This PR Reference
Containers ready for pickup 96 510 510
Demurrage risk 5,877 / 104 1,359 1,359
Discharged, not picked up 21,195 1,608 1,608

Demurrage trace: one call, list_containers {requires_attention: true, sort: attention_priority}, sent actively_tracked: true and read meta.total: 1359.

Risk

History questions now need include_stopped_tracking: true; the description says so. The contract helper ignores the default so an unfiltered list isn't reported as filtered.

Tests

390 MCP tests pass; type check and lint clean.

🤖 Generated with Claude Code

Historical queries now explicitly include both active and stopped records; stopped-only queries use actively_tracked: false (or shipment tracking_stopped: true). SDK request tests preserve these distinctions, and historical/stopped-only agent cases are added on feat/askt49-eval-runner as follow-up coverage; live runs remain pending.

…ashboard

Containers and shipments lists now add actively_tracked=true unless the caller
sets actively_tracked or tracking_stopped, or passes include_stopped_tracking
for history. Tool descriptions carry the dashboard definitions for ready for
pickup, at risk and discharged-not-picked-up, and ask for the set's total
before any narrowing.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@vercel

vercel Bot commented Oct 7, 2026 •

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated
api Ready Ready Preview Oct 8, 2026 4:18pm UTC

Request Review

@maurycy maurycy left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The actively tracked default is consistent with operational worklists and preserves explicit tracking filters. Approved; clarifying stopped-only queries and adding historical-query evaluations would be useful follow-ups.

@alosec

alosec commented Oct 7, 2026

Copy link
Copy Markdown
Contributor Author

(Codex) @maurycy clarified historical versus stopped-only queries, added passing SDK request regressions, and added historical/stopped-only agent-eval cases as follow-up coverage with live runs still pending.

@maurycy maurycy left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved. The historical versus stopped-only behavior is clarified and covered by SDK request regressions.

* feat(mcp): list_parties resolves company names to party IDs

list_parties turns a company name (customer, shipper, consignee, broker,
forwarder, dray carrier) into the party ID that advanced_filters.parties
needs, with one call to GET /v2/parties?query=. Rails already searches
company names there (whole words and word prefixes, ignoring case); the
OpenAPI spec didn't document the param, so the SDK and MCP couldn't use
it.

- OpenAPI: document query on GET /parties; SDK types regenerated.
- SDK: parties.list accepts { query } (PartyListOptions).
- MCP: list_parties passes search through and reports meta.total and
  truncated.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* chore: Auto-generate Postman collection from openapi.json [skip ci]

* docs(api): correct party search and tracking-request examples

* fix(mcp): page party matches and retain disambiguation context

* chore: regenerate party API types and reference artifacts

* chore: Auto-generate Postman collection from openapi.json [skip ci]

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
@dodeja

dodeja commented Oct 8, 2026

Copy link
Copy Markdown
Member

@claude rebase

@alosec

alosec commented Oct 10, 2026

Copy link
Copy Markdown
Contributor Author

Closing: everything here shipped to main through #411 (tracked-only default with include_stopped_tracking, the dashboard definitions in the list tool descriptions, and list_parties). Leaving the branch in place since #405 and #401 target it.

@alosec alosec closed this Oct 10, 2026

This branch was successfully deployed

1 active deployment
Preview — e3eb48dd Deployed Oct 8, 2026 by vercel[bot]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants