Loading ToolBench
Plan and execute reproducible scientific and engineering workloads across local compute, GPUs, Slurm, PBS, and LSF with preserved experiment provenance, artifacts, lineage, telemetry, and verification.
Project Bourne demonstrates solid domain-specific design with 23 well-structured tools covering scientific workload execution, provenance tracking, and HPC integration. Tool names follow verb_noun conventions (bourne_request_schema, bourne_validate_request, bourne_discover). Most tools have descriptions (194-char baseline met). However, parameter descriptions are inconsistent: some parameters lack detail (e.g., 'reference' appears 12 times with identical generic descriptions), and output schemas are not documented. Error handling guidance is absent. The PolicyApplicabilityDocument and ExecutionRequestDocument show sophisticated schema design, but many tools lack actionable error recovery hints. Security-sensitive operations (bourne_site_select, bourne_execution_submit) lack explicit permission/audit documentation.
Trace the provenance and lineage of an artifact.
Discover the local compute site's capabilities and inventory.
Discover a specific site's capabilities and inventory.
Request cancellation of a running execution.
Retrieve a specific execution.
List recorded executions.
Reconcile execution state with the scheduler and collect results.
Retrieve the result of a completed execution.
Generic parameter descriptions repeated across 12+ tools. 'reference' parameter appears identically in bourne_site, bourne_discover_site, bourne_execution_reconcile, bourne_execution_status, bourne_execution_cancel, bourne_execution_result, bourne_artifact_trace, bourne_inventory_get, bourne_workload_get, bourne_plan_get, bourne_execution_get with minimal context. LLMs cannot distinguish when to use canonical ID vs prefix vs @N notation without clearer guidance.
Output schemas not documented for any tool. Tools like bourne_discover, bourne_sites, bourne_execution_status return complex nested structures (capabilities, inventory, status objects) but LLMs have no schema to understand what fields to expect. This forces agents to guess field names and risks extraction errors.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | <=2025-11-25 | v2 |
Query the current status of an execution.
Submit an immutable execution plan for execution.
Retrieve a specific inventory snapshot.
List recorded inventory snapshots.
Retrieve a specific execution plan.
List recorded execution plans.
Retrieve the canonical execution request schema and metadata.
Get details about a specific configured site.
Explore viable resource candidates for an execution request at a specific site.
Submit one typed structured policy claim about a site.
Select a candidate and generate an immutable execution plan.
List all configured compute sites.
Validate an execution request document against the canonical schema.
Retrieve a specific workload specification.
List recorded workload specifications.
No error recovery guidance. Tools like bourne_site_select and bourne_execution_submit perform irreversible operations (WRITE/REVERSIBLE risk) but descriptions do not explain what errors can occur, whether they are retryable, or what the agent should do if selection fails. Missing pattern:recovery-guide.
Pagination not explicitly documented. Tools like bourne_inventory_list, bourne_workload_list, bourne_plan_list, bourne_execution_list accept 'limit' but descriptions do not mention offset/cursor, total count, or whether results are sorted. Large result sets risk context window exhaustion.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible in source. Risk classifications (READ_ONLY, WRITE, REVERSIBLE) are noted in the tool list but not exposed via MCP ToolAnnotations. Agents cannot programmatically determine which tools are safe to retry or have side effects.