Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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. reference is the site's exact name or canonical ID. Use this for a named local or SSH site; use bourne_discover for Bourne's current local context and bourne_site_inspect to read existing state. SSH discovery may require existing user authorization, uses only bounded typed probes, never accepts arbitrary commands, and never executes a scientific workload.

bourne_site_policy_claimA

Append one durable structured policy claim and provenance record to an existing configured site. reference is the exact site name or canonical ID; claim contains the asserted fact, evidence classification, source identity, and applicability. Use this for reviewed site constraints or advice before candidate generation; use bourne_site_discover to observe infrastructure. This stores no source document, fetches no URL, runs no command, and does not modify previous claims.

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_select; use bourne_plan when site-aware candidate comparison is unnecessary. This does not execute or durably persist a request or plan, but stores an ephemeral candidate session in this MCP process; a restart loses that session.

bourne_site_selectA

Choose one candidate returned by bourne_site_candidates, persist selection evidence, and create a new immutable execution plan without executing it. request_id and candidate_id must come from the same live candidate session; regenerate candidates after a server restart. This writes a new plan without editing existing plans. Review the returned plan before calling bourne_execute_plan; selection fails when required approvals, declarations, or provider trust are missing.

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 17 tools

Disambiguation4/5

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.

Naming Consistency3/5

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.

Tool Count3/5

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.

Completeness5/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues