bourne mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| bourne_request_schemaA | Return Bourne's canonical ExecutionRequest version-2 JSON Schema. |
| bourne_validate_requestA | Validate and normalize an ExecutionRequest v2 without discovery, planning, persistence, or execution. |
| bourne_discoverA | Run bounded local compute-site discovery and persist a new immutable inventory snapshot. |
| bourne_inventoryA | Read an existing inventory by latest, full ID, unique prefix, or @N; this never performs discovery. |
| bourne_site_listA | List configured non-secret local and SSH site contexts. |
| bourne_site_inspectA | Inspect one configured site, its policy claims, and inventory identities. |
| bourne_site_discoverA | Discover one configured site and persist a new immutable inventory snapshot linked to it. |
| bourne_site_policy_claimA | Append one durable structured policy claim and provenance record to an existing configured site. |
| bourne_site_candidatesA | Generate at most 64 candidate plans for one configured site from an ExecutionRequest, an existing inventory, and optional declarative provider constraints. Use after site discovery and before |
| bourne_site_selectA | Choose one candidate returned by |
| bourne_planA | Persist and resolve an ExecutionRequest v2 against an existing inventory. Planning never executes the workload and preserves ambiguity. |
| bourne_execute_planA | Execute one immutable persisted Bourne plan without changing its command, resources, placement, backend, or inventory. |
| bourne_execution_getA | Read a Bourne execution, including request, plan, lifecycle, scheduler, allocation, experiment, telemetry, and verification state. |
| bourne_execution_reconcileA | Reconnect and reconcile one exact Bourne-owned remote execution; never resubmit. |
| bourne_execution_waitA | Wait on one existing Bourne-managed scheduled execution with an optional bounded caller timeout; this creates no execution. |
| bourne_execution_cancelA | Cancel only the exact scheduler job owned by an existing Bourne execution; arbitrary scheduler job IDs are not accepted. |
| bourne_trace_artifactA | Trace a recorded output artifact to its producer, inputs, and experiment ancestry without guessing across ambiguous matches. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 17 tools
Most tools have clearly separated lifecycle roles: schema/validate/plan/execute/get/wait/cancel/trace are distinct. A few phrases overlap, notably bourne_plan versus bourne_site_candidates/bourne_site_select and bourne_discover versus bourne_site_discover, but the descriptions actively explain when to use each.
Every tool is prefixed with bourne, but the underlying pattern is inconsistent: validate_request and execute_plan are verb+object, site_list and execution_get are object+verb, while discover, inventory, and request_schema are bare or noun-only. Names remain readable, but the convention is not uniform.
17 tools is just above the ideal range and feels somewhat heavy for a single server. The planning workflow is split across plan, site_candidates, and site_select, which inflates the tool count even though the overall domain is coherent.
The tool set covers the stated execution lifecycle well: schema validation, request normalization, discovery, inventory, site policy, candidate planning, selection, immutable plan creation, execution, monitoring, wait, cancellation, reconciliation, and artifact tracing. No obvious operation needed by the domain seems missing.