Resources and tools

The Seamward MCP server exposes eight tools, six resources, and two prompts. Every one of them is read-only, idempotent, and non-destructive; nothing a client calls can change your workspace, your integrations, or your production systems.

Current registered contract

These are the names registered by the current server. Every tool is read-only and scoped to a previously reviewed workspace, mode and exact connection set. New hosted authorization reviews the exact mode and connection selection in browser consent. A zero-connection grant returns empty lists.

Every tool result and resource wraps its payload in the same envelope, so the client always knows which workspace the data came from. Counts and latest activity in the overview include only the reviewed mode and connections:

Code example

{  "schemaVersion": "seamward.mcp/1",  "workspace": { "id": "wks_2ac9017e", "name": "Acme", "slug": "acme" },  "data": { "...": "the tool-specific result" }}

Tools

Tool	Purpose	Required scope
`get_workspace_overview`	Workspace summary, integration health, incident counts	`seamward:workspace:read`
`list_integrations`	Page through integrations with health and both analysis states	`seamward:workspace:read`
`get_integration`	One integration with safe configuration and both analysis states	`seamward:workspace:read`
`list_incidents`	Page through incidents, optionally filtered by status	`seamward:incidents:read`
`get_incident`	One incident with findings and evidence references	`seamward:incidents:read`
`get_incident_replay`	Replay dataset metadata and deterministic run results	`seamward:repairs:read`
`get_repair_proposal`	One proposal with validation and decision provenance	`seamward:repairs:read`
`get_approved_repair_bundle`	Resource links for an approved repair bundle	`seamward:repairs:export`

Parameters

The two list tools share pagination parameters:

Parameter	Type	Constraints
`cursor`	string, optional	1 to 256 characters; omit for the first page
`limit`	integer, optional	1 to 100, default 25

The remaining tools each take one identifier:

Parameter	Used by	Format
`integrationId`	`get_integration`	Starts with `int_`
`incidentId`	`get_incident`, `get_incident_replay`	Opaque string, 1 to 128 characters
`proposalId`	`get_repair_proposal`, `get_approved_repair_bundle`	Starts with `rep_`
`status`	`list_incidents`, optional	`open` or `resolved`

get_workspace_overview takes no parameters. All tool inputs are strict: an unknown parameter is rejected rather than ignored.

Example call

A client listing open incidents sends:

Code example

{  "name": "list_incidents",  "arguments": { "status": "open", "limit": 10 }}

and receives the standard envelope with a page of incidents in data, including a cursor when more pages exist. Identifiers in results (such as incidentId values) feed directly into the single-item tools.

Tool errors

Failed calls return a stable error code instead of data:

Code	Meaning	What to do
`unauthorized`	The grant is no longer valid for this workspace	Reconnect and approve again
`forbidden`	The grant lacks the tool's required scope	Reconnect and approve the missing scope
`not_found`	The id is outside the reviewed selection or no longer exists	Check the id, mode and connection set
`internal_error`	Something failed on the Seamward side	Retry; report it if it persists

get_approved_repair_bundle additionally requires that the proposal is already approved and passes fingerprint checks; an unapproved proposal is never exported.

Resources

Clients that browse resources can read the same data by URI:

Resource URI	Contents	Required scope
`seamward://workspace/current/overview`	Workspace health summary	`seamward:workspace:read`
`seamward://workspace/current/integrations/{integrationId}`	One integration	`seamward:workspace:read`
`seamward://workspace/current/incidents/{incidentId}`	One incident with redacted evidence	`seamward:incidents:read`
`seamward://workspace/current/incidents/{incidentId}/replay`	Immutable replay evidence	`seamward:repairs:read`
`seamward://workspace/current/repairs/{proposalId}`	One repair proposal and validation record	`seamward:repairs:read`
`seamward://workspace/current/repairs/{proposalId}/export/{fileName}`	One file from an approved repair bundle	`seamward:repairs:export`

The export resource serves three files per approved proposal: repair.json (the machine-readable manifest), REPAIR.md (the readable report), and repair.ts (the TypeScript patch). All resources return JSON except the export files, which are served as text.

Prompts

Two prompts package common workflows so you can start them from your client's prompt picker:

investigate_seamward_incident takes an incidentId and guides an evidence-backed investigation: read the incident and its replay evidence, inspect your local repository separately, and keep Seamward evidence distinct from inference. It never changes production systems.
implement_approved_repair takes a proposalId and guides a local review change: confirm the proposal is approved, retrieve its bundle, and prepare a local patch with tests. It never merges or deploys.

Neither prompt can approve, deliver, or mutate anything in Seamward; they only direct the client to the read-only tools above.

Next steps

Authorization: which scopes unlock these tools and how to revoke a client.
MCP overview: connecting a client for the first time.

Integration list and detail results include structuralAnalysis and behavioralAnalysis with its current status, last completed pass and any capacity pause. The object follows the Workspace API state definition. Observation activity or zero open incidents alone does not prove that both forms of analysis completed.