# ScoreCompute > Specialized Rust computation tools for AI assistants. Website: https://scorecompute.com/ MCP endpoint: https://scorecompute.com/mcp Transport: MCP Streamable HTTP. No API key required for bounded public access. Use MCP initialize and tools/list to discover the current schemas and limits. Optional focused connection: https://scorecompute.com/mcp?tools=verify_claim exposes only Verify. The service-specific tools query accepts 1–8 distinct tool names; each selected tool keeps its full schema. The ordinary endpoint retains all tools. Reconnect after changing a selection; this is not an authorization boundary. The catalogue exposes 38 tools: 22 scientific computation tools, 6 independent Discovery study tools, 6 optional composition tools, 3 contributor-network tools and 1 claim-verification tool. Direct scientific and Discovery calls never require the composer. ## Guided first mission - https://scorecompute.com/guides/first-mission/: copyable English/French request, exact arguments and clearly dated private MCP execution record on synthetic data. No hosted chat model; the caller supplies its assistant. - https://scorecompute.com/missions/robust-route/: compose_capabilities previews the existing route-risk path; execute_composition runs route_optimizer, the explicit route_durations.v1 adapter and simulate_plan. This assesses one tour, not an optimization of robust tour choice. ## Direct computation tools - shape_the_sound: inverse design for a connected uniform fixed-edge ideal membrane. Ratios, tolerance windows, numerical search and optional actual mode meshes. Refinement reuses hear_the_shape, not an independent validator; search failure never proves impossibility. - check_arithmetic: bounded numerical claims with checked exact rational arithmetic where supported; unsupported estimates remain inconclusive. Directly callable independently of verify_claim. - simulate_pi: seeded Monte Carlo, CPU or NVIDIA CUDA, Wilson confidence interval. - optimize_tasks: exact 0/1 task selection under an integer time budget. - simulate_plan: uncertainty simulation for the selected task durations. - compute_orbit: ideal two-body Keplerian orbit, not an observational ephemeris. - hear_the_shape: 1–12 vibration modes of a simple 3–64-vertex polygon in metres, with fixed or free boundary conditions. P1 finite-element upper bounds and Richardson-extrapolated estimates remain distinct; estimated errors are not rigorous bounds. Optional wave speed supplies frequencies and notes; optional second polygon supplies a finite-resolution spectral comparison. Matching modes do not prove isospectrality. No damping, air loading, bending stiffness or holes. CPU, direct MCP access only: no planner binding or approved composition adapter. - propagate_uncertainty: check units for one explicit expression (512 characters, 1–16 variables), then compare first-order GUM with seeded Monte Carlo under supplied normal, uniform, triangular or constant input distributions. Fixed 10,000–2,000,000 draws, coverage 0.5–0.999; supported correlations are between normal inputs. Returns dimensional findings, uncertainty budgets, coverage intervals and a linearization/convergence assessment. No unlisted influences, effective degrees of freedom, affine Celsius/Fahrenheit units or adaptive draws. CPU, direct MCP access only: no planner binding or approved composition adapter. - verify_shadows: solar position and shadow geometry under supplied assumptions. - check_ephemeris: approximate Sun/Moon position against a claimed observation. - audit_statistics: GRIM/GRIMMER arithmetic checks under the stated assumptions. - analyze_kinematics: angular speed and distance hypotheses, no identification of an object. - check_shadow_track: temporal shadow consistency under a solar model. - solve_equilibrium: Kuhn poker strategy via self-play. - analyze_chess_game: comparison with Stockfish; not evidence of cheating. - screen_wash_trading: trade-pattern screening; not proof of manipulation. - route_optimizer: geometric CPU tours for 2-256 points, explicit planar or spherical km. Fixed start 0, optional return, all legs preserved. Exact only after complete small-instance search; bounded heuristics otherwise. No roads or traffic. - triangulate_tracks: bounded CPU fit of original timed geometric angle tracks from 2–4 stationary observers. Constant-velocity spherical ECEF model, declared angular standard deviations and supplied fixed clock offsets. Returns estimated, inconsistent, degenerate or no_convergence, fitted trajectory and conditional component uncertainties and the full conditional 6×6 covariance with units. No object identification or real-world accuracy promise. Corrected measurement times have a global span <=3600 s, overlapping observers and |t_s|<=1e12 s. Contract 0.2.0: interpolation supports initialization/output only, not extra independent measurements in the fit. Reduced chi-square >9 is a screening convention, not a three-sigma significance test. A complete request has a typed direct-tool binding; a fit does not itself supply future acquired observations. ## Method Lab: independent experimental tools - forge_route_policy: Rust generates, mutates and crosses bounded arithmetic route rules using supplied training cases only; complete ancestry and outcome ledger. Contract 0.2 uses cost-aware selection with converged-only admission. Logical fuel is a work proxy, not CPU cycles; simplification reports keep both hashes. Public bounds: 8 cases, 32 points/case, 64 attempted programs, fixed depot 0. - run_route_policy: explicitly run an experimental bounded AST on 2–128 planar kilometre points without retraining. Complete tour and cost checks; exact=false. - Neither tool automatically replaces route_optimizer or claims superiority. - A separate sealed study evaluates one locked train-selected candidate against nearest-neighbor + 2-opt and cheapest-insertion + 2-opt on fresh held-out cases. - Interactive formula and 3D tour: https://scorecompute.com/discovery/#method-lab - Campaign 1 receipts (preserved): https://scorecompute.com/research/method-forge/study.json - Campaign 2 receipts: https://scorecompute.com/research/method-lab-v2/study.json - These tools are independently callable; the typed composition catalogue has no bindings for them. ## Independent Discovery study tools - plan_observation: fit original supplied angular observations, then compare 1-64 proposed series at one common future horizon. Candidates supply a station, 3-120 corrected times, angular-noise assumptions and cost; they contain no new angles. Inspect predicted versus baseline_rejected and design.status. Ranking minimizes predicted major-axis position uncertainty among admissible supplied alternatives. Cost is a limit. This is a conditional local linear forecast, not an acquired posterior, a globally best viewpoint or a visibility guarantee. - stress_test_observation: examine 1-32 explicitly hypothetical angle/clock perturbations against a reconstruction-stability claim. counterexample_found may mean an excessive position shift or no usable reconstruction. none_found applies only to examined admissible cases; non-convergence is inconclusive. - assimilate_observation: refit original observations together with one supplied new angular series. Each old/new pair enters once; the original covariance is not reused as a prior. data_origin is synthetic or measured as declared by the caller, with data_provenance caller_declared_unverified. New readings can worsen uncertainty or contradict the model. A mean-position shift is not error against known truth. Forecast, before and refit uncertainty remain distinct. - improve_schedule: enumerate up to 32 permitted deadline/task-removal changes, preserve required tasks, compare declared costs and confirm one finalist using a separate fixed seed. Search and confirmation each have an error budget of 0.025; search controls the examined family. At most 10000 samples per evaluated alternative plus one confirmation; exact bounds use no fabricated simulation. confirmed is conditional on independent uniform duration variation. Minimality concerns the examined search-qualified choices, not every possible schedule. Observation tools derive their baseline from the original supplied tracks. Client baseline/state/covariance/truth fields, callbacks and unknown fields are rejected. The constant-velocity spherical ECEF model assumes exact stations and corrected clocks, and independent angular errors. Original time correction is corrected_time = t_s - clock_offset_s; proposed/new times are already corrected. Prediction, supplied data and caller-declared synthetic/measured provenance must remain separate in explanations. No tool activates a sensor or fabricates new measurements. Public examples use fixed synthetic data. These are bounded direct CPU tools, not a public autonomous or adaptive-policy research service. Laboratory: https://scorecompute.com/discovery/ Methods and limits: https://scorecompute.com/docs/discovery/ ## Optional native mission tools - list_capabilities: inspect native engine contracts, units, assumptions, backend and composition readiness, including the new direct-only engines. Catalogue inclusion does not imply a planner binding. Use list_composition_capabilities for the registered typed bank, which also describes triangulation and bound Discovery tools. Optional exact theme filter; unknown themes return an empty list. The original robust scheduling family remains available; the typed planner also supports route-risk composition. - plan_mission: validate a robust scheduling request and preview candidate budgets, engine-call and sample bounds, or explicit blockers, without executing engines. - build_robust_plan: compare up to three task selections in native Rust using optimize_tasks and, only when necessary, simulate_plan. Select the highest-value examined candidate that meets the requested success target under the stated model. Mission inputs require items, budget (integer minutes) and uncertainty (0 to 0.5). Defaults: min_success_rate 0.95, samples 10000 per candidate, seed 42, max_candidates 3, duration_model independent_uniform, allowed_tools [optimize_tasks, simulate_plan]. Candidates use nominal, 10% and 20% time reserves. Limits: 32 tasks, budget 1440 minutes, 20000 samples per candidate, 3 candidates. Unsupported duration models or missing required tool permissions produce blockers. Only approved local tools are supported, with no external commands or destinations. The native executor validates the integer-minute handoff, skips simulation when an exact worst-case bound suffices, and reuses identical selections within the same mission. Otherwise it uses fixed seeded Monte Carlo and simultaneous 95% Hoeffding error bounds across the examined family. A result is inconclusive if no candidate's lower bound meets the target; selected is then null. This is a conditional result under independent uniform duration variation, not a forecast guarantee or a globally optimal robust schedule over every possible selection. MCP progress messages prefixed SC_MISSION_EVENT: contain actual native event JSON. The entire mission is one composite MCP call. Its internal engine calls are native Rust calls, not extra MCP requests. Detailed mission events and results are private to the requesting client and are not published in the observatory. ## Typed capability planning and execution - list_composition_capabilities: inspect 22 implemented capabilities (15 base engines, four Discovery tools, two explicit duration adapters and one robust scheduling composite), 46 versioned fact contracts and reproducible requests. hear_the_shape and propagate_uncertainty remain outside this planner bank: call them directly. Other proposed engines are not advertised as implemented. - compose_capabilities: provide goals and available contract IDs, optional allowed tools/locality/search bounds and actual tool argument objects. Rust builds a dependency graph, explains blocked paths and returns an existing-tool binding where available. This is planning only; actual inputs are checked at execution. - execute_composition: recompile and execute the approved optimize_tasks -> selected_durations.v1 -> simulate_plan path. Supply optimize_tasks arguments and simulate_plan {budget, uncertainty, samples, seed}; do not supply durations. The adapter verifies selected identities, totals, integer-minute units and the shared deadline. Real events use the SC_COMPOSITION_EVENT: progress prefix. A second approved path is route_optimizer -> route_durations.v1 -> simulate_plan. Supply available contracts route_optimizer.request.v1, route.speed_kmh.v1, duration.independent_uniform.v1, sampling.fixed.v1 and budget.minutes.v1; goal simulate_plan.result.v1. Supply inputs.route_optimizer and inputs.simulate_plan, plus adapters["route_durations.v1"] = {"speed_kmh":60}. The speed is caller supplied (1-150 km/h). The adapter checks the complete route and converts each leg with ceil(distance_km / speed_kmh * 60). It refuses zero legs, more than 32 legs and per-leg durations outside 1-1440 minutes. The deadline is 1-1440 minutes; sampling is fixed at 100-20000 under the declared independent uniform model. This assesses one tour; it does not select a more robust tour or predict real traffic. Structural cost counts graph steps, not measured time, price or scientific quality. Defaults: local_only true, max_steps 8, max_search_states 512, max_structural_cost 64. Bounds: 1-8 goals, up to 48 available contracts, 1-16 steps, 1-2048 expanded states. Missing assumptions or tool permissions are blockers. Search exhaustion does not prove impossibility. Independent goals form a graph, not independent corroboration. The executor accepts 1-32 tasks, a 1-1440 minute shared deadline, uncertainty 0-0.5, and 100-20000 fixed samples. Success means the risk calculation finished, not that the schedule is safe. A 95% Hoeffding interval concerns sampling under the supplied model. Empty selections are blocked. Use build_robust_plan to compare the separate validated family of nominal/10%/20% reserve strategies against a probability target. Complete triangulation and Discovery requests can bind directly to their existing tool. These bindings do not create an acquisition adapter: predicted information cannot satisfy a contract requiring supplied new angles. Allowed-tool constraints accept up to 19 identifiers and retain required underlying permissions. Only approved execution bindings run. No arbitrary remote URLs or generated code. Documentation: https://scorecompute.com/docs/composition/ ## System availability https://scorecompute.com/status.json provides a sanitized timestamped monitoring snapshot. Discard stale snapshots (90 seconds) and future timestamps (>15 seconds). Status does not reserve a worker or guarantee a calculation will complete. GPU presence comes from worker inventory, not a periodic benchmark. Bounded local service recovery does not resume interrupted jobs or provide distributed failover. ## Interpretation and collaboration Return the model assumptions and limitations with every result. Physical compatibility does not establish image authenticity. A contradiction requires examining inputs and model assumptions. Never label a person fraudulent from these tools. Call optimize_tasks and simulate_plan independently to control each step yourself, or use the optional build_robust_plan tool to compare the bounded candidate family. Among the eighteen scientific tools, only simulate_pi currently implements CUDA. These synchronous tools follow the connected compute machine and do not use a persistent queue or distributed failover. The separate contributor network below has a bounded queue for two fixed synthetic workloads; it never receives private arguments from the scientific tools or executes arbitrary compositions. ## Public observatory The website displays declared MCP software client names and tool activity. Client names and versions are self-reported; the AI model's identity is not verified. Do not include secrets or personal data in clientInfo. Tool arguments and results are not published by the observatory. Recent activity is held in memory. ## Contributor network: fixed public computation Client 0.2.0, wire protocol sc-worker/0.1. Two compiled workloads are supported. pi_chunk_v1 is a separate indexed 31-bit integer Monte Carlo model, not the existing floating-point simulate_pi engine. schedule_probe_v1 is CPU-only and accepts only one of three fixed public scenarios; no private schedule is accepted. - network_status: read current contributor capacity, busy/available GPUs, offered CPU threads, reported GPU memory, worker supported_workloads and observed validated samples per second, including a breakdown by workload. - submit_network_job: queue a synthetic job with {samples:1000000,seed:42,backend:"auto"}. Supported samples: 100-5000000; seed: unsigned 32-bit. Workload defaults to pi_chunk_v1, with backend auto/cpu/cuda and no scenario_id. For schedule_probe_v1, supply scenario_id and backend cpu or auto; CUDA is refused. A queued ticket is not a completed result. No custom durations, files or private inputs are accepted. - get_network_job: pass the returned job_id to read progress or the final receipt. Only completed jobs have a final scientific result; queued/running/expired are not success. Schedule receipts keep inside and estimate null, and use successes, probability and probability_interval_95 instead of a pi estimate. The three compiled schedule scenarios are: - single_80_deadline_90: one 80-minute task, deadline 90 minutes. - pair_60_40_deadline_100: tasks of 60 and 40 minutes, deadline 100 minutes. - pair_60_40_deadline_110: tasks of 60 and 40 minutes, deadline 110 minutes. Each sequential task uses an independent 65536-point midpoint duration grid from 0.75 to 1.25 times its nominal value. This discrete model differs from continuous simulate_plan. Version: splitmix64-grid16-independent-uniform-quarter-v1. Completed jobs return a nominal fixed-sample Wilson 95% Bernoulli interval; it is not a real-world deadline guarantee or an adaptive stopping interval. Example submission: {"samples":1000000,"seed":42,"backend":"cpu", "workload":"schedule_probe_v1","scenario_id":"pair_60_40_deadline_110"}. Workers negotiate supported_workloads at registration. Omission and legacy state mean pi only. Existing registrations must be revoked and explicitly registered again to add a workload; replacing a binary does not expand consent. Scheduling uses only CPU resources explicitly enabled by their owner, even with backend auto. Every accepted chunk is independently recomputed on coordinator CPU. The network provides distributed contribution and checked results; this does not establish a net speedup. worker_reported_ms is untrusted summed worker time and may overlap across workers. verification_ms is coordinator CPU recomputation; coordinator_wall_ms includes queueing, transfer and validation. Keep these timing scopes separate. Chunks contain at most 250000 samples. Jobs expire after 120 seconds; leases expire after 20 seconds. Work is reassigned only within bounded coordinator rules. Jobs may fail to finish when clients pause, disconnect or become stale. Public HTTP equivalents: GET https://scorecompute.com/api/network/v1/status, POST https://scorecompute.com/api/network/v1/jobs and GET https://scorecompute.com/api/network/v1/jobs/{job_id}. Status contains checked_at_ms and stale_after_seconds (45 seconds). A stale or future snapshot does not establish present capacity. Resource identities and hardware are declared by clients, not attested. Public aliases, opaque IDs, hardware offers and synthetic job receipts are public; tokens, installation IDs and raw device IDs are not published. Do not use personal information as an alias. Observed throughput is accepted samples in the previous 60 seconds divided by 60. observed_samples_per_second_by_workload separates the two workloads. The aggregate mixes different calculations and is not a comparable scientific-work or FLOPS metric. GPU memory is separate per device, not pooled into a larger model allocation. The hosted scientific worker inventory is not added to the contributor totals. Only one physical RTX 4080 SUPER has been used for GPU validation; independent client processes are not evidence of multiple physical machines or GPUs. Contributor clients support Windows x64 and Linux x64. Windows is distributed as a ZIP containing an unsigned executable; Linux as a tar.gz with a glibc 2.39 baseline (Ubuntu 24.04). Published downloads and SHA-256 checksums are available in the contributor section of the live laboratory. A checksum is not a publisher signature. The NVIDIA driver must support the embedded PTX; no CUDA Toolkit is required to run the client. Device failure never silently enables CPU fallback. Every launch starts paused. CPU contribution is disabled on a fresh installation. Saved resource choices do not start computation. Explicit Start registers and enables work. Pause prevents new chunks; an existing small chunk may finish. GPU choices, 1-8 CPU threads (bounded by the machine) and duty are user controlled. Duty adds rest periods; it is not a wattage cap or GPU-kernel preemption. The local dashboard uses loopback and protected controls. The client installs no automatic startup service and executes only the negotiated compiled workloads. Guide: https://scorecompute.com/contribute/ Live pool and client downloads: https://scorecompute.com/lab/#network ## Contributor retention and privacy The coordinator retains at most 128 registrations, including aliases, declared resources and hashed authentication tokens. Registrations have no automatic age-based deletion; Pause does not delete them. Revoke removes the active registration and invalidates assignments, while prior verified job counts remain. At most 64 job records are kept, with terminal records pruned oldest-first when new admission needs space. The 120-second execution deadline is not a receipt retention period. Cumulative totals remain after pruning. IP admission buckets are memory-only and inactive buckets are reclaimed after 120 seconds. Restricted operational backups can contain earlier coordinator state; the 50-event MCP observatory limit is not an infrastructure-wide zero-storage claim. A separate contributor activity endpoint at https://scorecompute.com/api/network/v1/activity publishes synthetic transitions. Its ephemeral ring holds at most 256 events; a response includes at most 128 and a snapshot of up to 16 active plus eight terminal public job receipts. This 24-receipt snapshot does not change the 64-record persistent job limit. Events contain job IDs, timestamps, sample counts and sometimes short public worker IDs/backend, not credentials, IPs, full private worker IDs or aliases. The website may match short worker IDs to separately published status aliases. A lease is an assignment, not proof of kernel execution. Reset snapshots are history and must not be replayed as fresh work or GPU utilization. Coordinator restart clears event history without removing retained receipts. This journal is separate from the gateway's 50-event MCP observatory. Details and contact: https://scorecompute.com/privacy/ ## Interactive demonstrations Gallery: https://scorecompute.com/demos/ The 30 dedicated pages demonstrate tools of one MCP server. The Discovery laboratory covers its 6 study tools, and /verify/ provides arithmetic and claim verification. The catalogue contains 38 tools in total, not separate servers. Each demonstration provides real example arguments, explained methods and limitations. No calculation or contributor job starts on page load. The conceptual artwork illustrates a theme; it is not a scientific result. - [tour_profile](https://scorecompute.com/demos/tour-profile/): Compare a square, a line and two separated clusters. Inspect the supplied positions, then ask Rust for the distance distribution, isolation and directional spread. - [scan_counterexample](https://scorecompute.com/demos/scan-counterexample/): Declare a comparison, choose a discrete grid and look for a witness. See which cells were visited, where a violation was returned and why silence is never a proof. - [shape_the_sound](https://scorecompute.com/demos/shape-the-sound/): Choose a chord and ask Rust to design a polygonal membrane. Inspect the returned shape, animate its computed vibration modes and compare requested and obtained tones. - [kepler_stability](https://scorecompute.com/demos/kepler-stability/): Explore how nearby orbits separate in an ideal Sun–Jupiter system. Turn a grid of starting conditions into a sensitivity map, then inspect what each calculation actually established. - [hear_the_shape](https://scorecompute.com/demos/hear-the-shape/): Compare two drum shapes, see their calculated vibration modes and listen to individual frequencies. Explore what a finite spectrum can — and cannot — tell you about a shape. - [propagate_uncertainty](https://scorecompute.com/demos/propagate-uncertainty/): Follow uncertain inputs through a formula. Compare first-order propagation with seeded Monte Carlo, see which inputs contribute most, and catch incompatible units before calculating. - [plan_golden_hour](https://scorecompute.com/demos/plan-golden-hour/): Choose a date and location. Calculate the golden and blue light windows in one UTC day, including high-latitude cases where familiar sunrise patterns disappear. - [triangulate_tracks](https://scorecompute.com/demos/triangulate-tracks/): Combine timed angular observations from different locations to estimate a moving object’s 3D position and velocity, with residuals and explicit uncertainty limits. - [simulate_pi](https://scorecompute.com/demos/simulate-pi/): Turn a seeded cloud of random points into an estimate of π, with a convergence curve and sampling uncertainty you can inspect. - [optimize_tasks](https://scorecompute.com/demos/optimize-tasks/): Give independent tasks a duration and a value. Rust selects the highest-value combination that fits the stated time budget. - [simulate_plan](https://scorecompute.com/demos/simulate-plan/): Run a supplied plan through seeded duration variations and see how often it meets the deadline under that chosen model. - [route_optimizer](https://scorecompute.com/demos/route-optimizer/): Connect supplied points into a complete tour, then inspect every leg, the search method and whether optimality was actually established. - [compute_orbit](https://scorecompute.com/demos/compute-orbit/): Change the shape and elapsed time of an ideal orbit, then inspect its trajectory, position and orbital period. - [verify_shadows](https://scorecompute.com/demos/verify-shadows/): Compare a measured shadow with a calculated solar direction after mapping image pixels onto a declared ground plane. - [check_ephemeris](https://scorecompute.com/demos/check-ephemeris/): Compare a claimed Sun or Moon position with an approximate ephemeris at a supplied place and UTC time. - [audit_statistics](https://scorecompute.com/demos/audit-statistics/): Ask whether a reported mean or standard deviation passes necessary arithmetic checks for bounded integer observations. - [analyze_kinematics](https://scorecompute.com/demos/analyze-kinematics/): Convert observed angular motion into transverse speed at chosen distances and inspect the consequences of a claimed speed-distance pair. - [check_shadow_track](https://scorecompute.com/demos/check-shadow-track/): Compare supplied shadow angles over time with expected solar motion, including individual residuals and the direction of rotation. - [solve_equilibrium](https://scorecompute.com/demos/solve-equilibrium/): Explore a three-card imperfect-information game with regret-based self-play, a strategy table and explicit exploitability measurements. - [analyze_chess_game](https://scorecompute.com/demos/analyze-chess-game/): Ask Stockfish to assess supplied positions and compare the played moves with its bounded-depth recommendations. - [screen_wash_trading](https://scorecompute.com/demos/screen-wash-trading/): Examine a synthetic series for repeated volume at nearly identical prices, with a declared time window and price band. - [list_capabilities](https://scorecompute.com/demos/list-capabilities/): Inspect the thirteen registered composition-bank tool contracts, their themes, units, backends, assumptions and current readiness. - [plan_mission](https://scorecompute.com/demos/plan-mission/): Validate a robust-scheduling request and inspect its bounded candidate budgets, required tools and maximum work. - [build_robust_plan](https://scorecompute.com/demos/build-robust-plan/): Compare a bounded family of task selections, preserving their values while checking whether a declared success target is supported. - [list_composition_capabilities](https://scorecompute.com/demos/list-composition-capabilities/): Read the implemented engines, two explicit duration adapters and one scheduling composite alongside their versioned input and output facts. - [compose_capabilities](https://scorecompute.com/demos/compose-capabilities/): Start from available contracts and a desired result. Rust searches registered dependency paths while enforcing permissions and explicit limits. - [execute_composition](https://scorecompute.com/demos/execute-composition/): Execute an approved route-to-risk chain with checked identities, explicit units, caller-supplied speed and real native progress events. - [network_status](https://scorecompute.com/demos/network-status/): Read the contributor network’s fresh resource offers, busy GPUs and observed verified throughput without submitting a calculation. - [submit_network_job](https://scorecompute.com/demos/submit-network-job/): Queue a synthetic π experiment, receive a real ticket and follow counts that the coordinator verifies before aggregation. - [get_network_job](https://scorecompute.com/demos/get-network-job/): Supply a job_id returned by submit_network_job to inspect verified progress, completion or expiry for that public experiment. ## Golden and blue hour — plan_golden_hour Independently callable CPU engine. Input: {"date_utc":"2026-06-21T00:00:00Z","latitude":48.85,"longitude":2.35}. The period is one strict UTC day, not the local civil day. Golden elevation is [-4°, +6°]; blue is [-6°, -4°], geometric solar centre without refraction. Returns sorted millisecond windows, midpoint azimuths (nullable near zenith), period-boundary flags, conventional sunrise/sunset crossings at -0.833°, numerical diagnostics and limits. No terrain, weather or beautiful-light guarantee. Solar primitives are shared with the shadow/ephemeris engines: no independent corroboration. Demo: https://scorecompute.com/demos/plan-golden-hour/ Method: https://scorecompute.com/engines/plan-golden-hour/ Typed complete-request binding: plan_golden_hour.request.v1 → plan_golden_hour.result.v1. ## Validated observation policy The independent plan_observation tool can return policy_trace: version, evidence SHA-256 and actual execution path. Approved large requests use an exhaustive cached Fisher kernel; small requests retain the reference. A baseline rejection executes no ranking kernel. Inspect https://scorecompute.com/discovery/#capability-lab and https://scorecompute.com/research/observation-policy/study.json. Acceptance concerns a bounded synthetic CPU study, not GPU, network or whole-assistant acceleration. The methods are engineered; evidence packaging and validation are automated. ## Kepler sensitivity `kepler_stability` (native contract 0.2.0) reports a bounded planar circular Sun–Jupiter parameter map. Low/moderate/high bands measure finite-window separation, not chaos or long-term stability. Each cell includes actual integrated duration and stopping reason. Numerical warnings and uncomputed cells remain explicit; missing diagnostics are null. Radial overlap of the current osculating ellipse is not a physical encounter time. The engine returns no perturbed-trajectory time series. At most 512 cells and 4 million reserved outer steps, CPU only. Independently callable through MCP; no approved composition binding. Method: https://scorecompute.com/engines/kepler-stability/ ## Design a polygonal drum for a chord URL: https://scorecompute.com/engines/shape-the-sound/ Tool: shape_the_sound Published spectral inequalities first test whether all permitted ratios are excluded within the supplied tolerance windows. Otherwise bounded multi-start shape optimization searches polygonal membranes, then reanalyses the candidate on refined meshes using the same finite-element solver as hear_the_shape. Inputs: Supply one to five ascending frequency ratios between 1 and 4, 5–16 vertices, a tolerance of 0.5–100 cents, 50–1000 evaluations and a seed. Explicit wave speed and fundamental frequency allow numerical scaling. Optional computed mode shapes support 3D visualization. Outputs: An achieved, not_achieved or proven_impossible status. Search results include the actual polygon, measured ratios, errors and estimated uncertainty, evaluated work, diagnostics and optional mesh modes. An exclusion reports its theorem and full tolerance scope. Limitations: Uniform connected ideal membrane with a fixed edge only. Success is numerical and its estimated discretization error is not a rigorous bound. The forward check shares the same solver, so it is not independent corroboration. Search failure is not impossibility. Sound playback synthesizes computed frequencies; damping, air loading and manufactured instrument behavior are absent. CPU only, direct MCP access independent of orchestration. ## Check a numerical claim URL: https://scorecompute.com/engines/check-arithmetic/ Tool: check_arithmetic A bounded parser evaluates supported arithmetic using reduced i128 rational numbers. Exact comparisons include the supplied absolute and relative tolerance. Unsupported exact operations, transcendental functions and rational overflow yield an explicitly inconclusive floating estimate, not a certified error bound. Inputs: A scalar expression up to 512 characters, named numeric values, a claimed numeric value and optional tolerances. JSON numeric values and claims must stay inside the safe integer magnitude; precise large constants can be written in the expression string. Outputs: A consistent, inconsistent or undetermined result; exact rational value when available, computed estimate, error, tolerances, comparison mode, canonical digest and stated scope. Limitations: No units or factual interpretation. Exact support is bounded by i128 arithmetic. Floating estimates have no certified enclosure and do not establish compatibility. A digest is not a signature. Use Verify to obtain a separately signed, scoped calculation receipt. ## Kepler orbital sensitivity map URL: https://scorecompute.com/engines/kepler-stability/ Tool: kepler_stability A fourth-order Yoshida composition of Wisdom–Holman splitting advances two nearby trajectories using a universal-variable Kepler drift. Renormalized phase-space separation gives a finite-window sensitivity indicator. A sampled Jacobi invariant diagnostic and close-encounter guards identify unresolved numerical cases. Inputs: Choose semi-major axes in AU within 1.5–5.6, eccentricities 0–0.7, a 2–64 by 2–64 grid limited to 512 cells, a 50–5000 year window and 8–128 steps per year. Declare the initial perihelion phase, Jupiter mass ratio and orbital radius. The global budget reserves at most four million integration steps. Outputs: One entry per requested cell: heuristic low/moderate/high sensitivity or explicit encounter, numerical-warning, failure and uncomputed statuses. Results include actual integrated years, stopping reason, eccentricity maximum, phase-space growth, sampled relative Jacobi drift and osculating radial overlap when available. Reserved and completed work are separate counters. Limitations: A finite-window sensitivity band is not a chaos diagnosis or proof of long-term stability. A two-body integrable orbit can still show high finite-time sensitivity. Jupiter is circular, motion planar and particles massless; other planets and relativity are absent. A radial overlap is not a physical encounter. Discrete encounter guards can miss passages between samples. Jacobi drift below the warning threshold does not certify trajectory accuracy. The engine returns a parameter map, not a time series of perturbed trajectories. CPU only; independently callable, orchestration disabled. ## Hear the shape of a polygonal drum URL: https://scorecompute.com/engines/hear-the-shape/ Tool: hear_the_shape Rust assembles piecewise-linear finite elements on three nested meshes to solve the fixed-edge or free-edge Laplacian problem. Finite-element eigenvalues and Richardson-extrapolated estimates are reported separately. The finest mesh is bounded to 50,000 triangles; a smaller mesh can carry normalized mode values for visualization. Inputs: Supply a simple polygon with 3–64 vertices in metres, optionally repeating its first point at the end. Coordinates are bounded to ±10,000 m. Request 1–12 modes with fixed or free boundary conditions. An optional second polygon enables comparison; an explicit wave speed in m/s enables frequencies and musical notes. Outputs: Eigenvalue upper bounds under the stated numerical assumptions, extrapolated estimates and estimated errors, resolution warnings, nodal-domain counts, modal ratios and optional frequencies. A comparison returns congruent, spectra_differ or not_distinguished_at_this_resolution. Optional mode shapes describe the ideal numerical membrane. Limitations: No holes, curved boundaries, bending stiffness, air loading or damping are modelled. Extrapolation errors are estimates, not rigorous uncertainty bounds. A finite set of matching modes does not prove isospectrality. Frequencies depend on the supplied wave speed and are not a recording of a real drum. CPU only; directly callable over MCP, with no planner binding or approved cross-engine adapter. ## Measurement uncertainty with checked units URL: https://scorecompute.com/engines/propagate-uncertainty/ Tool: propagate_uncertainty A bounded expression parser checks dimensions and converts compatible units. Forward-mode derivatives produce a first-order GUM uncertainty budget. Fixed-sample Monte Carlo in ten seeded blocks propagates normal, uniform, triangular or constant inputs. The tool compares the first-order and simulated coverage intervals and reports convergence or undefined draws explicitly. Inputs: Provide an expression of at most 512 characters and 1–16 named variables with values, distributions and optional units. Supply standard uncertainty for a normal input or half-width for uniform/triangular inputs. Correlations may be declared between normal inputs. Choose 10,000–2,000,000 samples, a seed, coverage from 0.5 to 0.999 and an optional compatible result unit. Outputs: A located dimensional inconsistency or model result with first-order sensitivities, a per-variable budget, simulated summaries and coverage intervals, linearization assessment, convergence information and a formatted statement. No uncertainty, undefined draws and insufficient Monte Carlo convergence are distinct outcomes. Limitations: Unlisted influences are absent from the model. Inputs are independent unless a supported correlation is declared. First-order coverage uses a normal approximation without effective degrees of freedom. Celsius and Fahrenheit are refused because their conversions are affine; use kelvin. Sampling is fixed rather than adaptively increased. Coverage is conditional on the supplied distributions and model, not a guarantee about an instrument. CPU only; directly callable over MCP, with no planner binding or approved cross-engine adapter. ## Golden and blue hour windows in Rust URL: https://scorecompute.com/engines/plan-golden-hour/ Tool: plan_golden_hour A bounded CPU scan refines solar-elevation crossings and extrema, including grazing windows near midnight. Golden elevation is −4° to +6°; blue is −6° to −4°. Window classification follows the solar centre above an ideal horizon without refraction. Inputs: Provide date_utc as YYYY-MM-DDT00:00:00Z (a UTC day, not a local civil day), latitude −89° to 89° and east-positive longitude −180° to 180°. Years 1900–2100 are accepted. Outputs: Sorted UTC millisecond windows, durations, midpoint azimuths when defined, rising/setting direction, period-boundary flags, threshold crossings, daily elevation extrema and numerical diagnostics. Paris and Tromsø examples are reproducible. Limitations: Clouds, buildings, terrain and atmospheric conditions are not modelled. Numerical tolerance is not astronomical uncertainty. Conventional sunrise/sunset at −0.833° is separate from the end of golden light. The solar source is shared with the shadow and ephemeris tools, so agreement is not independent corroboration. Independent oracle fixtures validate selected dates, not the full accepted date range. ## 3D motion from multiple angular observers URL: https://scorecompute.com/engines/triangulate-tracks/ Tool: triangulate_tracks Stationary observers provide original timed angle measurements and fixed clock corrections. A bounded weighted least-squares solver fits six position/velocity parameters in a spherical Earth-fixed frame, assuming one object at constant velocity. A common grid supports initialization and samples the displayed trajectory; interpolated points are not independent fit observations. Inputs: Supply 2–4 observers, each with latitude between −89° and 89°, longitude ±180°, altitude −500 to 9000 m, declared angular standard deviations 0.01–10°, and 3–120 strictly time-ordered geometric angle samples. Azimuth is 0° to 360°, elevation −2° to 90°. Fixed clock offsets are supplied in seconds, not estimated. Corrected timestamps across all measurements span at most 3600 s, must overlap between observers, and each raw timestamp is bounded to ±10¹² s. Observer separation is at most 1000 km. Outputs: A status (estimated, inconsistent, degenerate or no_convergence), Earth-fixed state, component standard deviations, a 6×6 covariance matrix with its parameter units, geographic trajectory samples, per-observer residuals and solver diagnostics. The demonstration uses synthetic observations of a northbound object initially at 1000 m, moving at 200 km/h; it is not a real sighting. Limitations: Constant velocity, a spherical Earth and exact observer positions/clock corrections are declared assumptions. Refraction is not modelled and low elevations are flagged. Component uncertainties are local conditional approximations, not calibrated real-world error guarantees. Reduced chi-square above 9 is a screening convention, not a formal three-sigma test. A two-observer fit can absorb systematic bias. No result identifies the object or its origin. This tool is independently callable; it has no approved cross-engine composition adapter. ## Geometric tour optimization in Rust URL: https://scorecompute.com/engines/route-optimizer/ Tool: route_optimizer The start is fixed at input index 0. Completed Held–Karp search certifies the numerical optimum for at most 13 points; larger instances use nearest-neighbour construction and bounded 2-opt improvements. A cooperative time budget and deterministic work budget limit the search. Every returned tour is complete. Inputs: Supply 2–256 points with metric euclidean_km and x/y in kilometres, or great_circle_km and lat/lon in degrees. The spherical radius is declared as 6371.0088 km. Choose whether to return to the start and a 100–10000 ms time budget. Outputs: The complete order and every leg, total geometric distance, exact flag, method, stopping reason, nearest-neighbour reference, work count and measured native time. The optional route-risk chain verifies the legs before converting them to whole-minute durations using a supplied speed. Limitations: These are geometric distances, not a road network, traffic estimate or vehicle routing model. Heuristic tours have no claimed global optimality. Time-limited search can return a different best tour on different runs. Assessing one route under a declared uncertainty model is not optimization of its robustness. ## Monte Carlo simulation with Rust and CUDA URL: https://scorecompute.com/engines/simulate-pi/ Tool: simulate_pi The engine samples points uniformly in a unit square and counts those inside the quarter circle. Four times that proportion estimates π. Random values depend on the seed and global sample index, so worker assignment does not change the experiment. Inputs: Provide 100 to 5,000,000 samples, an integer seed and a CPU or CUDA backend. Optionally select CUDA device IDs from the available hardware. Outputs: The result includes the estimate, absolute error, Wilson interval, convergence history, a bounded sample for plotting, execution time and device provenance. Limitations: The interval describes sampling uncertainty, not a guarantee that every estimate meets a particular accuracy. GPU validation covers one physical device; multi-GPU execution is not independently validated. A CUDA request fails explicitly when CUDA is unavailable; it does not silently switch to CPU. ## Exact task selection under a time budget URL: https://scorecompute.com/engines/optimize-tasks/ Tool: optimize_tasks This is a bounded 0/1 knapsack problem: each task can be selected once. Dynamic programming searches the value achievable at each integer budget. The result is optimal for the supplied values and constraints. Inputs: Provide a budget of 1 to 1,440 minutes and up to 32 tasks, each with a name, integer duration and non-negative value. Outputs: The selected tasks, their total duration and total value can be passed directly to the schedule simulator. Assistants can call both tools independently; the optional native mission composer validates this handoff internally and compares bounded candidate selections. Limitations: Tasks must be independent. Dependencies, calendar dates, multiple machines and resource conflicts are not modelled. The value score is supplied by the caller; the engine does not infer business priorities. ## Schedule uncertainty simulation URL: https://scorecompute.com/engines/simulate-plan/ Tool: simulate_plan Each task duration is perturbed independently within a uniform relative uncertainty range. Repeated scenarios produce a mean duration, empirical 95th percentile and fraction of scenarios meeting the budget. Inputs: Pass selected durations, a time budget, sample count, seed and relative uncertainty. The direct tool accepts your own plan. The optional native composer uses a fixed sample count per candidate only when an exact duration bound is insufficient. Outputs: The probability estimate and duration summaries let an assistant compare a high-value plan with its sensitivity to delays. The output records the simulation assumptions. Limitations: Real delays may be correlated or heavy-tailed. Uniform independent perturbations are a chosen scenario model, not a forecast learned from operational data. Success in the simulation does not guarantee delivery. ## Keplerian orbit calculation for AI agents URL: https://scorecompute.com/engines/compute-orbit/ Tool: compute_orbit The model places a body in a Keplerian orbit around one solar mass. It solves Kepler’s equation and returns the object position at the requested elapsed time, along with a sampled trajectory. Inputs: Specify the semi-major axis in astronomical units, eccentricity and elapsed days since periapsis. Supported axes range from 0.1 to 30 AU and eccentricity from 0 to 0.9. Outputs: A sampled orbit, position, distance from the focus and period are suitable for an explanatory plot or a follow-up numerical calculation. Limitations: This is an idealised educational model. It omits perturbations, relativity, multiple bodies and an observed epoch. It is not an ephemeris service for locating a real planet in the sky. ## Solar shadow geometry verification URL: https://scorecompute.com/engines/verify-shadows/ Tool: verify_shadows A solar model predicts the horizontal shadow direction from a UTC timestamp and location. Control points map image pixels onto a reference ground plane. Monte Carlo perturbations propagate uncertainty into the angular comparison. Inputs: Supply date and coordinates, calibrated pixel-to-ground control points and the endpoints of a shadow segment. Ground coordinates must use the documented orientation and scale; a photograph alone is insufficient. Outputs: The engine returns compatible, contradicted or untestable, with solar angles, measured and expected direction, uncertainty and reasons. Excessive uncertainty or inconsistent controls can make the result untestable. Limitations: The ground is assumed horizontal and reference points must be reliable. Perspective, terrain, lens distortion, multiple light sources and incorrect metadata can invalidate the model. Compatibility never proves that an image is authentic. ## Sun and Moon position consistency URL: https://scorecompute.com/engines/check-ephemeris/ Tool: check_ephemeris The engine calculates solar and lunar coordinates and compares the claimed azimuth and elevation using angular separation. Lunar coordinates include an observer correction on WGS84 at sea level; atmospheric refraction uses a standard model. Inputs: Supply date, latitude, longitude, object, claimed azimuth and elevation, and tolerance in degrees. The object codes in the current tool schema are soleil and lune. Outputs: Calculated positions, angular separation, adopted tolerance, lunar phase and a conditional compatibility result support a transparent check of a specific claim. Limitations: The nominal model margin is conventional rather than independently certified. Atmospheric conditions, altitude and uncertain observation times matter. Near-horizon observations need particular care; use a specialist ephemeris for precision astronomy. ## GRIM and GRIMMER statistics checks URL: https://scorecompute.com/engines/audit-statistics/ Tool: audit_statistics GRIM tests whether an integer sum can produce a reported rounded mean at a given sample size. The standard-deviation screening also considers the possible sums compatible with rounding and necessary integer second-moment conditions. Inputs: Provide sample size, reported mean, decimal precision, optional standard deviation and the minimum and maximum integer response values. Outputs: The result reports inconsistencies, nearest reachable quantities and the assumptions used. Consistent means that the implemented filters found no contradiction; it does not reconstruct or verify the original observations. Limitations: These tests apply only when the measurement and rounding assumptions hold. A flag is a reason to investigate transcription, methods and data, not evidence of research misconduct. Passing necessary conditions is not proof of a valid dataset. ## Angular motion and minimum speed URL: https://scorecompute.com/engines/analyze-kinematics/ Tool: analyze_kinematics The calculation relates angular motion to transverse speed through v = ω × distance, with the angular rate converted to radians. A claimed speed can then be compared with the speed required at a claimed distance. Inputs: Provide angular speed in degrees per second and distance or speed hypotheses. The tool exposes bounded parameter ranges through tools/list. Outputs: Speed-distance comparisons and profiles help an assistant explain what the observation would imply under each hypothesis. Limitations: The result does not identify an object or determine its actual distance. Camera motion, perspective, tracking quality and a line-of-sight velocity component can change the interpretation. An unknown object does not establish an extraordinary origin. ## Temporal shadow consistency in video URL: https://scorecompute.com/engines/check-shadow-track/ Tool: check_shadow_track A solar model predicts the change in horizontal shadow direction over the supplied time samples. The engine compares drift and per-sample residuals so opposite errors cannot cancel into a false compatibility result. Inputs: Supply a starting UTC date, geographic coordinates and samples containing elapsed minutes and measured shadow azimuth. Set an angular tolerance appropriate to measurement quality. Outputs: Expected and measured slopes, residuals and a conditional verdict can reveal a timeline or speed mismatch worth examining. Limitations: This version consumes extracted measurements. It does not automatically decode videos or detect shadows in uploaded footage. Camera motion, moving objects, uneven ground and unreliable reference directions can invalidate the comparison. ## Kuhn poker equilibrium with CFR+ URL: https://scorecompute.com/engines/solve-equilibrium/ Tool: solve_equilibrium The solver applies regret-based self-play to two-player Kuhn poker. It reports decision probabilities, game value and exploitability rather than interpreting the behaviour of real players. Inputs: Choose a bounded iteration count. The demonstration uses 200,000 iterations; increasing the count explores convergence for this particular toy game. Outputs: A strategy table, estimated game value and exploitability make the computation inspectable. The analytical reference game value is −1/18 for the first player. Limitations: Matching a game value alone does not prove that a strategy is unexploitable. This model is not a general poker solver and provides no guarantee for casino games or financial decisions. ## Chess move comparison with Stockfish URL: https://scorecompute.com/engines/analyze-chess-game/ Tool: analyze_chess_game For each legal supplied position, the engine queries Stockfish through UCI and compares the played move with its best choice at a bounded search depth. Centipawn differences and match rates are descriptive indicators. Inputs: Provide positions as FEN plus a played move in SAN or UCI notation, and a supported search depth. The web form includes a small reproducible example. Outputs: Per-move comparisons, average loss and an aggregate profile can support discussion of a game without identifying or accusing a player. Limitations: The analysis has a total runtime deadline. Large batches or deep searches can end with an explicit timeout. Good human moves can match an engine; these indicators do not establish cheating or the source of assistance. ## Trade-pattern consistency screening URL: https://scorecompute.com/engines/screen-wash-trading/ Tool: screen_wash_trading The engine screens time, price and volume records for recycling-like patterns under a chosen window and price tolerance. It reports the strength of this pattern without claiming to identify account ownership. Inputs: Supply a bounded array of timestamp, price and volume records, plus a time window and percentage price band. The transport accepts request bodies up to 1 MiB. Outputs: Recycled-volume ratio, round-trip counts, price span and timing summaries describe the observed pattern and explain why it may merit further examination. Limitations: The engine has no exchange account graph, beneficial ownership or counterparty identity. Normal market-making and other trading behaviour may create similar patterns. A screening flag is not proof of market manipulation or investment advice. ## Planar tour instance profile URL: https://scorecompute.com/engines/tour-profile/ Tool: tour_profile Pairwise distance statistics, k-nearest isolation in the Method Lab convention, centroid centrality, PCA collinearity, mirror residual across the better principal axis when those axes are determined, an eight-bin distance histogram and a rounded fingerprint. Deterministic and geometry-only. Inputs: Provide 3 to 256 planar points with finite coordinates in consistent units, and optionally a reference distance fraction between 0.01 and 0.5 for the close-pair test. Outputs: The full descriptor set, the histogram and a rounded fingerprint, with explicit limits. The principal-axis mirror residual is null for isotropic noncoincident covariance. It recommends no method, promotes nothing and validates no benefit. Limitations: Descriptors only: no method recommendation, no benefit claim, and equal fingerprints do not prove that two instances are equivalent. Euclidean planar geometry only; no roads, time or uncertainty. ## Bounded counterexample scan URL: https://scorecompute.com/engines/scan-counterexample/ Tool: scan_counterexample A fixed lexicographic grid scan (last variable fastest) evaluates the claim expression <= bound or >= bound with an explicit tolerance, capped by an evaluation budget, and returns the first witnesses with their margins. Inputs: Provide the expression, the relation (le or ge), the bound, optional tolerance, one to six variable domains (min, max, 2–64 steps) and optional evaluation and counterexample caps. Outputs: The scanned fraction, completeness, explicit stopping reason and numerical witnesses with values and margins. Undefined and near-boundary evaluations are counted separately and can leave the result inconclusive. Limitations: Float64 screening only: the numerical guard is not a certified interval or formal proof. A witness concerns a sampled point; absence covers only resolved evaluated cells, never the continuous box. This does not replace domain-specific stress tests. ## Method Atlas https://scorecompute.com/discovery/method-atlas/ Recorded routing-method gains and losses, 3D tour replays, family summaries and source hashes. Historical evidence from two completed campaigns; neither candidate was promoted. No new solver evaluations. ## Interactive MCP demonstrations One MCP server, 30 individual tool exhibits plus 6 Discovery tools in the laboratory; no automatic execution on opening a page. ### tour_profile: Read the geometry before choosing a method. URL: https://scorecompute.com/demos/tour-profile/ Compare a square, a line and two separated clusters. Inspect the supplied positions, then ask Rust for the distance distribution, isolation and directional spread. Supply the point cloud: Use 3–256 planar points in consistent coordinate units. The plot previews those exact positions with equal axis scales; point labels are not a tour. Measure the structure: Rust returns distance statistics, neighbour isolation, PCA spread and an eight-bin distance histogram. An ambiguous principal direction can make the mirror residual unavailable. Compare without overclaiming: Use the descriptors to inspect differences between inputs. No algorithm is recommended and no route improvement, method promotion or equivalence is established. Example arguments: {"points":[{"x":0,"y":0},{"x":1,"y":0},{"x":1,"y":1},{"x":0,"y":1},{"x":0.5,"y":0.5}]} Limitations: - Distances use the supplied coordinate units in a Euclidean plane. Roads, travel time, terrain and uncertainty are absent. - The PCA ratio is zero for a line and approaches 0.5 for isotropic spread. A principal direction can be ambiguous; unavailable mirror measurements remain explicit. - The fingerprint is rounded and can collide. Equal fingerprints are not a proof that point clouds are equivalent. - The plots show supplied points and returned descriptors; they do not produce scientific measurements themselves. Direct MCP access does not require orchestration. ### scan_counterexample: Find the point that breaks a claim. URL: https://scorecompute.com/demos/scan-counterexample/ Declare a comparison, choose a discrete grid and look for a witness. See which cells were visited, where a violation was returned and why silence is never a proof. State the claim and grid: Supply an expression, ≤ or ≥, its bound and tolerance, then one to six finite variable ranges. The interface previews up to two dimensions and 512 cells. Scan in a fixed order: The last variable varies fastest. Rust stops at a fixed evaluation budget, the witness limit or the end of the grid. Undefined and numerically uncertain comparisons remain separately counted. Inspect the witness or limit: Returned variable values, expression values and margins identify a numerical counterexample. A completed finite scan without a witness is not a proof over the continuous domain. Example arguments: {"expression":"x ^ 2","relation":"le","bound":4,"variables":[{"name":"x","min":-3,"max":3,"steps":7}],"max_counterexamples":1,"max_evaluations":200} Limitations: - The scan uses finite Float64 evaluations and a numerical comparison guard, not interval arithmetic or a certified symbolic proof. - Absence of a witness covers only evaluated cells. Unvisited positions, values between grid cells and other variable ranges remain outside the observation. - Undefined expressions or comparisons too close to classify can make the result inconclusive. Such cells are never silently counted as passing. - The grid illustration uses requested coordinates, the returned visit count and returned witnesses. It does not invent function values or evaluate the expression in the browser. - The tool is directly callable by MCP. It has no approved planner adapter and does not replace a domain-specific stress test. ### shape_the_sound: Give a sound its shape. URL: https://scorecompute.com/demos/shape-the-sound/ Choose a chord and ask Rust to design a polygonal membrane. Inspect the returned shape, animate its computed vibration modes and compare requested and obtained tones. Describe the chord: Supply ascending ratios for the lowest modes and a tolerance in cents. Feasibility theorems can exclude the entire window for the stated fixed-edge, uniform membrane model. Search for a shape: A bounded multi-start search adjusts a polygon. The interface waits for the actual result: it does not invent intermediate shapes, progress percentages or a successful candidate. Inspect and listen: The returned shape is reanalysed on three refined meshes with the shared forward solver. Animate returned eigenvectors and play quiet sine tones from requested or returned frequencies, only on your click. Example arguments: {"target_ratios":[1.25,1.5],"tolerance_cents":5,"fundamental_hz":196,"wave_speed":120,"vertices":10,"max_evaluations":300,"seed":1,"include_mode_shapes":true} Limitations: - The model is a connected, uniform, planar membrane with a fixed edge. Free edges, nonuniform materials, damping and air coupling are outside its scope. - A bounded search that does not meet the target is not a proof of impossibility. An exact-target exclusion is distinct from exclusion of the full tolerance window. - The final check reuses the forward finite-element solver. Estimated discretization errors are not rigorous bounds and do not constitute independent certification. - The fundamental is numerically tuned when both fundamental_hz and wave_speed are supplied. Returned values and resolution warnings remain authoritative. - Modal displacement is normalized and exaggerated; animation is slowed. Playback uses synthetic sine tones, not a physical drum model or recording. - The number of evaluations is bounded; the native engine does not guarantee a maximum wall-clock duration. ### kepler_stability: A small change. A different orbit? URL: https://scorecompute.com/demos/kepler-stability/ Explore how nearby orbits separate in an ideal Sun–Jupiter system. Turn a grid of starting conditions into a sensitivity map, then inspect what each calculation actually established. Choose the starting orbits: Each tile represents one initial semi-major axis and eccentricity. The orbit view shows that initial geometry; it is not a reconstructed perturbed trajectory. Measure finite-time sensitivity: Rust advances two nearby trajectories in a planar, circular Sun–Jupiter model. Their separation and a sampled invariant diagnostic produce the returned map, within a fixed work budget. Inspect the evidence: Select a tile to see its actual integrated duration, stopping reason and diagnostics. A warning, unresolved encounter or uncomputed cell remains visibly distinct from a sensitivity measurement. Example arguments: {"mass_ratio":0.0009537,"jupiter_semi_major_au":5.2044,"max_work_units":4000000,"a_min_au":2.1,"a_max_au":3.5,"e_min":0,"e_max":0.35,"n_a":21,"n_e":9,"duration_yr":300,"steps_per_year":64,"initial_phase_deg":0} Limitations: - Low, moderate and high are heuristic finite-window sensitivity bands. They do not prove chaos or long-term stability; even an integrable orbit can show high finite-time sensitivity. - The model has a circular Jupiter, a massless particle and planar motion. Other planets, inclination, relativity and real ephemerides are absent. - The 3D orbit is initial geometry derived from the parameters. Body sizes and diagnostic heights use explanatory scales; the engine does not return a perturbed trajectory time series. - Radial overlap uses the instantaneous osculating ellipse. It does not identify an actual encounter or collision time. - Close-encounter guards sample numerical substeps and can miss passages between samples. A small sampled Jacobi drift does not certify trajectory accuracy. - Cells that do not fit the work budget are not calculated. Actual integrated duration may be shorter than the requested window, and completed steps differ from reserved work. ### hear_the_shape: Different shapes. The same notes? URL: https://scorecompute.com/demos/hear-the-shape/ Compare two drum shapes, see their calculated vibration modes and listen to individual frequencies. Explore what a finite spectrum can — and cannot — tell you about a shape. Choose the geometry: Define a polygon in metres, a fixed or free boundary and an optional wave speed. The first example uses two different reference polygons; their outlines are shown before any calculation. Calculate the vibrations: Rust solves the ideal membrane eigenproblem on three finite-element meshes. The returned modal values deform the 3D surface; the visible oscillation is deliberately slowed. Compare, then listen: Select a mode, compare the returned frequencies and inspect mesh-resolution warnings. Playback is a pure sine at a returned frequency, not a recording or synthesis of a real drum. Example arguments: {"polygon":[[0,0],[0,2],[4,6],[4,4],[6,4],[4,2],[2,2],[2,0]],"compare_polygon":[[2,0],[0,2],[0,4],[4,4],[4,6],[6,4],[4,2],[2,2]],"boundary":"fixed","modes":8,"wave_speed":343,"include_mode_shapes":true} Limitations: - A finite numerical spectrum that is not distinguished at this resolution does not prove exact isospectrality. - The model is an ideal two-dimensional membrane. Air coupling, material stiffness, damping and strike position are not included. - Coordinates are metres. A supplied wave speed converts eigenvalues into frequencies; 343 m/s is an illustrative input, not a measured membrane property. - Mesh differences estimate numerical error; they are not rigorous error bounds. Under-resolved modes remain labelled. - Surface amplitude is normalized and exaggerated for readability. Animations are slowed; sound uses the returned frequency and requires an explicit click. ### propagate_uncertainty: How certain is your answer? URL: https://scorecompute.com/demos/propagate-uncertainty/ Follow uncertain inputs through a formula. Compare first-order propagation with seeded Monte Carlo, see which inputs contribute most, and catch incompatible units before calculating. Describe the measurements: Supply a formula, units, input distributions and any supported normal-input correlations. An uncertainty is a declared model input, not something inferred from a single number. Compare two calculations: Automatic derivatives propagate first-order uncertainty. A separate seeded Monte Carlo evaluates the same declared model and checks numerical convergence. Inspect the useful differences: The 3D bench and calibrated interval view use returned contributions and interval endpoints. No histogram or simulated samples are invented by the interface. Invalid dimensions produce a diagnostic instead of a result. Example arguments: {"expression":"x1 + x2 + x3 + x4","variables":[{"name":"x1","value":0,"unit":"","distribution":"normal","standard_uncertainty":1},{"name":"x2","value":0,"unit":"","distribution":"normal","standard_uncertainty":1},{"name":"x3","value":0,"unit":"","distribution":"normal","standard_uncertainty":1},{"name":"x4","value":0,"unit":"","distribution":"normal","standard_uncertainty":1}],"coverage":0.95,"samples":1000000,"seed":7} Limitations: - Reported uncertainty is conditional on the supplied formula, distributions and correlations. Unmodelled biases are not covered. - A first-order interval may be inadequate for a nonlinear model. More Monte Carlo draws do not repair an invalid physical model. - A convergence diagnostic concerns the sampling calculation; it is not a guarantee about a real measurement. - Signed correlation contributions are shown separately. Independent variance shares must not be read as the complete correlated budget. - The illustration is conceptual. Only a completed call supplies numerical intervals and contribution heights. ### plan_golden_hour: Find the light before you go. URL: https://scorecompute.com/demos/plan-golden-hour/ Choose a date and location. Calculate the golden and blue light windows in one UTC day, including high-latitude cases where familiar sunrise patterns disappear. Choose a place and a UTC day: Latitude and east-positive longitude locate the observer. The period starts at 00:00 UTC and ends at the next UTC midnight, not local midnight. Find the threshold crossings: Rust searches geometric solar-centre elevation: −4° to +6° for golden light, −6° to −4° for blue light. Refraction is not added. Read the returned windows: Inspect each interval, its duration and midpoint azimuth. Boundary flags identify windows already open at midnight or continuing into the next day. Example arguments: {"date_utc":"2026-06-21T00:00:00Z","latitude":48.85,"longitude":2.35} Limitations: - These are explicit photographic conventions, not universal definitions or a forecast of beautiful light. - The horizon is ideal. Terrain, buildings, clouds, aerosols and weather are not modeled. - The separate −0.833° crossing is a solar-centre convention, not an official refracted upper-limb sunrise. - The 0.25-second search tolerance is numerical precision, not astronomical accuracy. Timestamp resolution is one millisecond. - The input domain is 1900–2100; independent oracle tests cover selected reference cases, not every date in that range. ### triangulate_tracks: Where do the sightlines meet? URL: https://scorecompute.com/demos/triangulate-tracks/ Combine timed angular observations from different locations to estimate a moving object’s 3D position and velocity, with residuals and explicit uncertainty limits. Align the supplied observations: Two to four stationary observers provide geometric azimuth/elevation tracks, declared angular standard deviations and optional fixed clock corrections. Clock corrections use a shared time origin; a bounded common grid supports initialization and the displayed trajectory. Fit one declared motion model: Weighted least squares fits the original timed measurements to a constant-velocity trajectory in a spherical Earth-fixed frame. This synthetic example starts at 1000 metres and moves north at 200 km/h; no real sighting or identity is claimed. Inspect what the geometry supports: Read estimated, inconsistent, degenerate or no_convergence, plus the fitted path, component standard deviations, the 6×6 covariance with declared units and per-observer residuals. A fitted state is not an identification of the object. Example arguments: {"observers":[{"lat":48.85,"lon":2.35,"elevation_m":35,"clock_offset_s":0,"sigma_az_deg":0.2,"sigma_el_deg":0.2,"samples":[{"t_s":0,"azimuth_deg":101.991260935,"elevation_deg":14.447682585},{"t_s":10,"azimuth_deg":93.467590277,"elevation_deg":14.732612639},{"t_s":20,"azimuth_deg":84.786897815,"elevation_deg":14.70245413},{"t_s":30,"azimuth_deg":76.336410848,"elevation_deg":14.362974947},{"t_s":40,"azimuth_deg":68.446289854,"elevation_deg":13.773863939},{"t_s":50,"azimuth_deg":61.324990456,"elevation_deg":13.022637731},{"t_s":60,"azimuth_deg":55.051414611,"elevation_deg":12.194843666},{"t_s":70,"azimuth_deg":49.607028444,"elevation_deg":11.356342386},{"t_s":80,"azimuth_deg":44.917906873,"elevation_deg":10.549458666},{"t_s":90,"azimuth_deg":40.888140057,"elevation_deg":9.79700007},{"t_s":100,"azimuth_deg":37.420214884,"elevation_deg":9.108372913}]},{"lat":48.85,"lon":2.45,"elevation_m":35,"clock_offset_s":0,"sigma_az_deg":0.2,"sigma_el_deg":0.2,"samples":[{"t_s":0,"azimuth_deg":258.008739065,"elevation_deg":14.447682585},{"t_s":10,"azimuth_deg":266.532409723,"elevation_deg":14.732612639},{"t_s":20,"azimuth_deg":275.213102185,"elevation_deg":14.70245413},{"t_s":30,"azimuth_deg":283.663589152,"elevation_deg":14.362974947},{"t_s":40,"azimuth_deg":291.553710146,"elevation_deg":13.773863939},{"t_s":50,"azimuth_deg":298.675009544,"elevation_deg":13.022637731},{"t_s":60,"azimuth_deg":304.948585389,"elevation_deg":12.194843666},{"t_s":70,"azimuth_deg":310.392971556,"elevation_deg":11.356342386},{"t_s":80,"azimuth_deg":315.082093127,"elevation_deg":10.549458666},{"t_s":90,"azimuth_deg":319.111859943,"elevation_deg":9.79700007},{"t_s":100,"azimuth_deg":322.579785116,"elevation_deg":9.108372913}]}]} Limitations: - Stationary observers and constant velocity on a 6371.0088 km spherical Earth are explicit assumptions. These are supplied angle measurements, not automatic video or photo analysis. - Refraction is not modelled; low-elevation samples are flagged. Clock offsets must be supplied, and systematic biases can be partly absorbed by a two-observer fit. - Reported standard deviations are local, model-based approximations using the declared errors. They do not include unmodelled refraction, sensor bias or clock error and are not independently calibrated accuracy guarantees. - The reduced chi-square cutoff of 9 is an explicit screening convention. Inconsistent concerns the supplied single-object motion model, never an accusation or a conclusion about origin. ### simulate_pi: Find π in a cloud of points. URL: https://scorecompute.com/demos/simulate-pi/ Turn a seeded cloud of random points into an estimate of π, with a convergence curve and sampling uncertainty you can inspect. Make the experiment repeatable: A seed and global sample indices define the points. CPU worker assignment does not change that experiment. Count the points inside: Rust counts points inside a quarter circle. Four times their fraction estimates π; this engine also has an explicit CUDA backend. Read the uncertainty: Inspect the estimate, a 95% Wilson interval, convergence history and the measured execution backend. Example arguments: {"samples":200000,"seed":42,"backend":"cpu"} Limitations: - The default example runs on CPU. CUDA must be requested explicitly and requires available compatible hardware. - A confidence interval is not a guarantee that this individual run achieves a chosen accuracy. - This floating-point experiment differs from the contributor network’s pi_chunk_v1 integer grid. No speedup is implied by this illustration. ### optimize_tasks: Make every minute count. URL: https://scorecompute.com/demos/optimize-tasks/ Give independent tasks a duration and a value. Rust selects the highest-value combination that fits the stated time budget. State the trade-off: Each task has a caller-supplied value and a whole-minute duration. A task can be included at most once. Search the budget states: Dynamic programming solves the bounded 0/1 knapsack problem exactly for these inputs. Keep the useful details: The result preserves selected identities, durations and totals so another tool can inspect or simulate the selection. Example arguments: {"items":[{"name":"Engine integration","duration":60,"value":90},{"name":"Documentation","duration":35,"value":65},{"name":"Validation","duration":45,"value":75},{"name":"Demo","duration":25,"value":40},{"name":"Review","duration":30,"value":60}],"budget":120} Limitations: - The optimum concerns the supplied values and independent-task model, not a business objective inferred by AI. - Dependencies, calendars, resource conflicts and multiple machines are not represented. - Nominal durations do not include delays; simulate_plan can assess a separately declared uncertainty model. ### simulate_plan: What happens when tasks run late? URL: https://scorecompute.com/demos/simulate-plan/ Run a supplied plan through seeded duration variations and see how often it meets the deadline under that chosen model. Declare the model: Each positive whole-minute duration varies independently within a uniform relative range. The example uses ±25%. Explore fixed scenarios: Rust samples the declared number of scenarios with the supplied seed and sums the varied durations. Inspect deadline sensitivity: Read the simulated success fraction, mean total duration and empirical 95th percentile. Example arguments: {"durations":[60,35,25],"budget":120,"samples":10000,"seed":42,"uncertainty":0.25} Limitations: - Independent uniform variation is an explicit scenario assumption, not a forecast learned from operational data. - Correlated delays or heavy-tailed durations can change the result substantially. - A high simulated success rate does not guarantee delivery. This tool evaluates a plan; it does not optimize its selection. ### route_optimizer: Find a shorter way around. URL: https://scorecompute.com/demos/route-optimizer/ Connect supplied points into a complete tour, then inspect every leg, the search method and whether optimality was actually established. Choose the distance convention: Use planar x/y coordinates in kilometres or great-circle latitude/longitude on a declared sphere. The start is input index 0. Search within limits: Small instances can complete exact Held–Karp search; larger ones use nearest-neighbour construction and bounded 2-opt improvements. Read a complete tour: Every point and leg remains present. The exact flag and stopping reason distinguish a completed proof from a bounded heuristic result. Example arguments: {"metric":"euclidean_km","points":[{"x":0,"y":0},{"x":1,"y":0},{"x":1,"y":1},{"x":0,"y":1},{"x":0.5,"y":0.5}],"return_to_start":true,"time_budget_ms":1000} Limitations: - These are geometric distances, not roads, traffic estimates or a vehicle-routing model. - Exact is true only after complete exact search. A heuristic tour is not claimed to be globally optimal. - Time-limited searches may stop at different improvements on different hardware. Speed is not measured against a competitor here. ### compute_orbit: Follow an ellipse through time. URL: https://scorecompute.com/demos/compute-orbit/ Change the shape and elapsed time of an ideal orbit, then inspect its trajectory, position and orbital period. Describe an ellipse: Supply a semi-major axis in astronomical units and an eccentricity between 0 and 0.9. Solve the position: Rust solves Kepler’s equation for elapsed days since periapsis around a one-solar-mass central body. See the geometry: The output includes the sampled ellipse, position, distance from the focus and period in days. Example arguments: {"semi_major_au":1.52,"eccentricity":0.0934,"elapsed_days":180} Limitations: - This educational two-body model has no observed epoch and does not locate a real planet in the sky. - Perturbations, other bodies, relativity and non-elliptical trajectories are omitted. ### verify_shadows: Does the shadow fit the Sun? URL: https://scorecompute.com/demos/verify-shadows/ Compare a measured shadow with a calculated solar direction after mapping image pixels onto a declared ground plane. Calibrate the ground: Four or more control points relate image pixels to ground metres east and north. This example is synthetic; it does not upload a photograph. Predict and compare: The solar model predicts a horizontal shadow direction for the stated UTC date and location. The calibrated shadow supplies a measured direction. Propagate measurement uncertainty: Monte Carlo perturbations help determine whether the comparison is compatible, contradicted or untestable under the supplied assumptions. Example arguments: {"date_utc":"2026-06-21T11:52:00Z","latitude":48.85,"longitude":2.35,"control_points":[{"px":[100,800],"world":[0,0]},{"px":[200,800],"world":[10,0]},{"px":[100,700],"world":[0,10]},{"px":[200,700],"world":[10,10]}],"shadow":{"a":[150,750],"b":[150,650]},"pixel_sigma":3,"time_sigma_minutes":1,"seed":7,"samples":1000} Limitations: - A horizontal ground plane, trustworthy reference points and a relevant solar-lighting model are required. - Lens distortion, terrain, multiple lights and uncertain metadata can invalidate the comparison. - Compatibility does not authenticate an image; contradiction asks for investigation of both measurements and assumptions. ### check_ephemeris: Put a sky claim in context. URL: https://scorecompute.com/demos/check-ephemeris/ Compare a claimed Sun or Moon position with an approximate ephemeris at a supplied place and UTC time. Locate the observer: The date, latitude and longitude define the observation. The current object codes are soleil for Sun and lune for Moon. Calculate the sky geometry: Approximate solar and lunar models produce azimuth and elevation. The Moon includes topocentric parallax for a sea-level WGS84 observer. Measure the angular gap: The engine compares the claimed and calculated directions and reports the adopted tolerance, reasons and a conditional finding. Example arguments: {"date_utc":"2026-09-30T22:00:00Z","latitude":48.85,"longitude":2.35,"object":"lune","claimed_azimuth_deg":81,"claimed_elevation_deg":27.1,"tolerance_deg":2} Limitations: - The model margin is conventional, not an independently certified accuracy guarantee. - Altitude, atmosphere and observation-time uncertainty matter, especially near the horizon. - This is a consistency check, not precision navigation or evidence that a photograph is authentic. ### audit_statistics: Can that rounded mean exist? URL: https://scorecompute.com/demos/audit-statistics/ Ask whether a reported mean or standard deviation passes necessary arithmetic checks for bounded integer observations. State the reporting rules: Specify sample size, reported precision and the allowed integer response range. Standard deviation is optional. Check possible sums: GRIM checks whether rounding an attainable integer sum could produce the reported mean. Inspect necessary conditions: When supplied, sample standard deviation is screened using compatible sums and integer second-moment conditions. Read the actual issues and nearest attainable quantities. Example arguments: {"n":10,"mean":3.48,"decimals":2,"min_value":1,"max_value":5} Limitations: - These checks apply only when integer observations and the specified rounding rules describe the data. - Passing necessary conditions does not reconstruct a dataset or prove one exists. - A flagged inconsistency can reflect transcription or methodological differences; it is not an accusation of fraud. ### analyze_kinematics: Distance changes the speed story. URL: https://scorecompute.com/demos/analyze-kinematics/ Convert observed angular motion into transverse speed at chosen distances and inspect the consequences of a claimed speed-distance pair. Measure angular motion: Supply an angular rate in degrees per second, independently of any story about the object. Vary the distance assumption: Rust converts the angle to radians and applies transverse speed = angular rate × distance. Inspect the implication: Compare the minimum transverse speed required at the claimed distance with the claimed speed and illustrative profile limits. Example arguments: {"angular_speed_deg_per_s":1,"distance_min_km":0.01,"distance_max_km":400000,"claimed_distance_km":10,"claimed_speed_kmh":600} Limitations: - Angular motion alone does not identify an object or establish its distance. - Camera motion, tracking errors, perspective and line-of-sight motion can alter the interpretation. - Illustrative profiles are not classifications or evidence of an extraordinary origin. ### check_shadow_track: Read time in a moving shadow. URL: https://scorecompute.com/demos/check-shadow-track/ Compare supplied shadow angles over time with expected solar motion, including individual residuals and the direction of rotation. Supply a measured sequence: Each point contains elapsed minutes and horizontal shadow azimuth in degrees. The example is a synthetic series. Calculate expected solar motion: The location and starting UTC date define the expected shadow direction at every supplied time. Compare slopes and residuals: The engine checks rate, direction and per-sample disagreement so opposite errors cannot cancel into a false agreement. Example arguments: {"date_utc":"2026-06-21T08:00:00Z","latitude":48.85,"longitude":2.35,"samples":[{"minutes":0,"azimuth_deg":277.56},{"minutes":30,"azimuth_deg":284},{"minutes":60,"azimuth_deg":291.16},{"minutes":90,"azimuth_deg":299.32},{"minutes":120,"azimuth_deg":308.82},{"minutes":150,"azimuth_deg":320.01}],"tolerance_deg":5} Limitations: - This version reads extracted angle measurements; it does not decode or track shadows in uploaded video. - Moving cameras, moving objects, terrain and unreliable directional references can invalidate the model. - A conditional mismatch does not identify the reason for that mismatch or authenticate a video. ### solve_equilibrium: Watch a tiny game find balance. URL: https://scorecompute.com/demos/solve-equilibrium/ Explore a three-card imperfect-information game with regret-based self-play, a strategy table and explicit exploitability measurements. Use a fully specified game: The solver runs two-player Kuhn poker, a deliberately small game with an analytical reference value of −1/18 for player one. Accumulate a strategy: CFR+ self-play updates action regrets and returns average action probabilities at each information set. Check vulnerability: Pure best responses measure exploitability. Read this alongside game value; value alone does not certify an equilibrium strategy. Example arguments: {"iterations":20000} Limitations: - The model is Kuhn poker, not a general poker solver or advice for gambling. - A finite iteration run is an approximation; inspect measured exploitability rather than assuming convergence. ### analyze_chess_game: Compare moves without accusing players. URL: https://scorecompute.com/demos/analyze-chess-game/ Ask Stockfish to assess supplied positions and compare the played moves with its bounded-depth recommendations. Provide legal positions: Each input contains a FEN position and a played move in SAN or UCI. The default example is a supplied six-ply opening line. Playback validates legal moves locally; it does not evaluate them or call Stockfish. Query a bounded engine: Rust uses Stockfish UCI at the requested depth, within a total runtime deadline. Read the profile: Per-position recommendations, first-choice agreement and centipawn loss describe similarity at that search depth. Example arguments: {"positions":[{"fen":"rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1","played":"e4"},{"fen":"rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq - 0 1","played":"e5"},{"fen":"rnbqkbnr/pppp1ppp/8/4p3/4P3/8/PPPP1PPP/RNBQKBNR w KQkq - 0 2","played":"Nf3"},{"fen":"rnbqkbnr/pppp1ppp/8/4p3/4P3/5N2/PPPP1PPP/RNBQKB1R b KQkq - 1 2","played":"Nc6"},{"fen":"r1bqkbnr/pppp1ppp/2n5/4p3/4P3/5N2/PPPP1PPP/RNBQKB1R w KQkq - 2 3","played":"Bb5"},{"fen":"r1bqkbnr/pppp1ppp/2n5/1B2p3/4P3/5N2/PPPP1PPP/RNBQK2R b KQkq - 3 3","played":"a6"}],"depth":8} Limitations: - A strong human move can match an engine. This profile never establishes cheating or the source of assistance. - Search depth and position selection affect the result; a 25-second deadline can produce an explicit timeout. - Stockfish must be installed on the connected compute worker. ### screen_wash_trading: Inspect a repeating market pattern. URL: https://scorecompute.com/demos/screen-wash-trading/ Examine a synthetic series for repeated volume at nearly identical prices, with a declared time window and price band. Supply the observed records: Records contain timestamps in seconds, prices and volumes. The example intentionally repeats a simple synthetic pattern. Apply the declared window: Rust screens nearby records for repeated-volume patterns within the permitted price band and time window. Inspect descriptive indicators: Recycled-volume ratio, cycle counts and price/timing summaries make the detected pattern inspectable. Example arguments: {"trades":[{"ts_s":1000,"price":100,"volume":10},{"ts_s":1010,"price":100.04,"volume":10},{"ts_s":1020,"price":100,"volume":10},{"ts_s":1030,"price":100.04,"volume":10},{"ts_s":1040,"price":100,"volume":10},{"ts_s":1050,"price":100.04,"volume":10},{"ts_s":1060,"price":100,"volume":10},{"ts_s":1070,"price":100.04,"volume":10},{"ts_s":1080,"price":100,"volume":10},{"ts_s":1090,"price":100.04,"volume":10},{"ts_s":1100,"price":100,"volume":10},{"ts_s":1110,"price":100.04,"volume":10},{"ts_s":1120,"price":100,"volume":10},{"ts_s":1130,"price":100.04,"volume":10},{"ts_s":1140,"price":100,"volume":10},{"ts_s":1150,"price":100.04,"volume":10},{"ts_s":1160,"price":100,"volume":10},{"ts_s":1170,"price":100.04,"volume":10},{"ts_s":1180,"price":100,"volume":10},{"ts_s":1190,"price":100.04,"volume":10},{"ts_s":1200,"price":100,"volume":10},{"ts_s":1210,"price":100.04,"volume":10},{"ts_s":1220,"price":100,"volume":10},{"ts_s":1230,"price":100.04,"volume":10},{"ts_s":1240,"price":100,"volume":10},{"ts_s":1250,"price":100.04,"volume":10},{"ts_s":1260,"price":100,"volume":10},{"ts_s":1270,"price":100.04,"volume":10},{"ts_s":1280,"price":100,"volume":10},{"ts_s":1290,"price":100.04,"volume":10}],"window_s":3600,"price_band_pct":0.25} Limitations: - The input has no account ownership, counterparties or beneficial-owner graph. - Ordinary market making and other benign activity can produce similar patterns. - A screening flag is not proof of manipulation, an accusation or investment advice. ### list_capabilities: Read the engines’ contracts. URL: https://scorecompute.com/demos/list-capabilities/ Inspect the thirteen registered composition-bank tool contracts, their themes, units, backends, assumptions and current readiness. Ask the native registry: The catalogue is built from implemented tool contracts. An optional exact theme filter narrows the response. Inspect scientific assumptions: Read the units, limits and supported execution backends before choosing a tool. Keep tools independent: The optional composer uses these contracts, but each direct tool remains callable through the same MCP connection. Example arguments: {} Limitations: - This is discovery only; it runs no computation and does not reserve a worker. - A listed capability is not a promise of current hardware availability. - Composition readiness applies to the implemented families, not every conceivable pairing. The independent triangulation engine is available directly, outside this catalogue. ### plan_mission: Preview the work before it runs. URL: https://scorecompute.com/demos/plan-mission/ Validate a robust-scheduling request and inspect its bounded candidate budgets, required tools and maximum work. Declare the scheduling mission: Tasks, deadline, duration uncertainty and success target define the request. Tool permissions stay explicit. Validate assumptions: Rust checks the supported independent-uniform duration model, bounds and local tools. Unsupported contracts produce blockers. Preview the bounded family: The preview describes up to three budgets: nominal, 10% reserve and 20% reserve, with bounds on engine calls and samples. Example arguments: {"items":[{"name":"Engine integration","duration":60,"value":90},{"name":"Documentation","duration":35,"value":65},{"name":"Validation","duration":45,"value":75},{"name":"Demo","duration":25,"value":40},{"name":"Review","duration":30,"value":60}],"budget":120,"uncertainty":0.25,"min_success_rate":0.95,"samples":10000,"seed":42,"max_candidates":3,"duration_model":"independent_uniform","allowed_tools":["optimize_tasks","simulate_plan"]} Limitations: - This is a plan preview. No optimizer or simulator has run and no schedule has been evaluated. - Candidate budgets are predeclared strategies, not freely invented scientific procedures. - Planning estimates work bounds; it does not promise measured latency, price or an optimal robust schedule. ### build_robust_plan: Choose value with room for uncertainty. URL: https://scorecompute.com/demos/build-robust-plan/ Compare a bounded family of task selections, preserving their values while checking whether a declared success target is supported. Select candidate schedules: Native Rust explores nominal, 10% reserve and 20% reserve budgets using the exact task-selection engine. Spend only needed simulation work: Exact worst-case checks can settle a candidate without simulation. Otherwise fixed seeded samples assess it; identical selections reuse their evaluation within this mission. Make a qualified choice: Among examined candidates, select the highest-value one whose simultaneous 95% sampling lower bound meets the target. If none qualifies, report inconclusive. Example arguments: {"items":[{"name":"Engine integration","duration":60,"value":90},{"name":"Documentation","duration":35,"value":65},{"name":"Validation","duration":45,"value":75},{"name":"Demo","duration":25,"value":40},{"name":"Review","duration":30,"value":60}],"budget":120,"uncertainty":0.25,"min_success_rate":0.95,"samples":10000,"seed":42,"max_candidates":3,"duration_model":"independent_uniform","allowed_tools":["optimize_tasks","simulate_plan"]} Limitations: - The conclusion is conditional on independent uniform duration uncertainty and the caller’s task values. - Only the bounded candidate family is compared; this is not global robust optimization over every possible schedule. - One composite MCP call produces real internal native events, not multiple external MCP calls. ### list_composition_capabilities: Explore the bank of typed capabilities. URL: https://scorecompute.com/demos/list-composition-capabilities/ Read the implemented engines, two explicit duration adapters and one scheduling composite alongside their versioned input and output facts. Discover the trusted bank: The current registry exposes 16 implemented capabilities and 34 versioned fact contracts. Inspect the connections: Inputs and outputs have semantic types, units and model assumptions. An adapter is a registered conversion, not a guess that two JSON objects fit. Reuse a declared example: Catalogue examples include direct calculations, approved risk chains and cases blocked by missing assumptions or permissions. Example arguments: {} Limitations: - The registry does not discover or approve arbitrary third-party MCP servers. - Sixteen capabilities include internal adapters and a composite; they are not sixteen separate public servers. - Reading the bank does not execute engines or prove that every graph is executable. ### compose_capabilities: Let Rust assemble an admissible path. URL: https://scorecompute.com/demos/compose-capabilities/ Start from available contracts and a desired result. Rust searches registered dependency paths while enforcing permissions and explicit limits. Declare the desired result: This example asks for a schedule-risk result from a geometric route request, an explicit speed and declared uncertainty/sampling facts. Follow compatible contracts: The bounded planner can connect route optimization, a checked kilometre-to-minute adapter and simulation. Missing facts or tool permissions block paths. Explain the selected graph: Read the selected steps, examined alternatives, search completeness, blockers and any approved execution binding. Example arguments: {"goals":["simulate_plan.result.v1"],"available":["route_optimizer.request.v1","route.speed_kmh.v1","duration.independent_uniform.v1","sampling.fixed.v1","budget.minutes.v1"],"inputs":{"route_optimizer":{"metric":"euclidean_km","points":[{"x":0,"y":0},{"x":1,"y":0},{"x":1,"y":1},{"x":0,"y":1}],"return_to_start":true,"time_budget_ms":1000},"simulate_plan":{"budget":4,"uncertainty":0.25,"samples":10000,"seed":42}},"adapters":{"route_durations.v1":{"speed_kmh":60}}} Limitations: - This tool plans only: the route and risk result have not been calculated yet. - Structural cost counts registered graph steps, not measured time, money or scientific quality. - Available facts are declarations. Actual arguments are validated again at execution; search exhaustion does not prove impossibility. ### execute_composition: A route becomes a checked risk study. URL: https://scorecompute.com/demos/execute-composition/ Execute an approved route-to-risk chain with checked identities, explicit units, caller-supplied speed and real native progress events. Recompile the approved plan: Rust validates the request and runs the geometric route engine. The separate task-selection-to-risk family is also supported. Verify the handoff: The adapter checks all route legs against the original points, recomputes distances and rounds each distance/speed duration up to whole minutes. Assess the supplied deadline: The simulator evaluates independent uniform variations. A receipt includes outputs, events, measured calls and a model-conditional 95% Hoeffding sampling interval. Example arguments: {"goals":["simulate_plan.result.v1"],"available":["route_optimizer.request.v1","route.speed_kmh.v1","duration.independent_uniform.v1","sampling.fixed.v1","budget.minutes.v1"],"inputs":{"route_optimizer":{"metric":"euclidean_km","points":[{"x":0,"y":0},{"x":1,"y":0},{"x":1,"y":1},{"x":0,"y":1}],"return_to_start":true,"time_budget_ms":1000},"simulate_plan":{"budget":4,"uncertainty":0.25,"samples":10000,"seed":42}},"adapters":{"route_durations.v1":{"speed_kmh":60}}} Limitations: - The four-kilometre square at 60 km/h gives four one-minute nominal legs. With ±25% variation and a four-minute budget, completion of this assessment does not mean timely arrival is likely enough. - Speed is a declared geometric conversion, not a traffic estimate. Zero-length legs and unsupported bounds are rejected instead of silently removed. - Only the two approved risk families execute here. This assesses one route; it does not search for a more robust tour or run arbitrary graph paths. ### network_status: See the pool that is actually offered. URL: https://scorecompute.com/demos/network-status/ Read the contributor network’s fresh resource offers, busy GPUs and observed verified throughput without submitting a calculation. Read a timestamped snapshot: The coordinator tracks contributor heartbeats and marks stale or paused resources unavailable. Separate resource types: GPU counts, per-device memory and explicitly offered CPU threads remain separate quantities. Read observed activity: Throughput counts samples accepted during the previous 60 seconds divided by 60; it is a recent observation for this fixed workload. Example arguments: {} Limitations: - Hardware and aliases are reported by contributors, not authenticated hardware identities. - VRAM across devices does not form one larger GPU allocation. Existing scientific-worker inventory is not counted again. - Stale snapshots do not prove present capacity. Offered resources and observed throughput do not guarantee completion or net speedup. ### submit_network_job: Send a small experiment to the pool. URL: https://scorecompute.com/demos/submit-network-job/ Queue a synthetic π experiment, receive a real ticket and follow counts that the coordinator verifies before aggregation. Submit bounded public parameters: A sample count, seed and backend preference define the fixed pi_chunk_v1 workload. Submitting creates a public job ticket. Distribute small chunks: Consenting clients pull leases of at most 250,000 samples. CPU and CUDA implementations use the same indexed 31-bit integer experiment. Verify before counting: The coordinator recomputes every accepted chunk on CPU. Read the returned job_id with get_network_job to distinguish queued work from a completed result. Example arguments: {"samples":1000000,"seed":42,"backend":"auto"} Limitations: - This action creates a real public job; it does not upload files, private datasets or arbitrary programs. - Workers may pause, disconnect or be unavailable. Jobs expire after 120 seconds and can remain incomplete. - Full CPU verification proves submitted counts for this experiment, not net acceleration or hardware identity. Its integer model differs from simulate_pi. ### get_network_job: Follow a real ticket to its receipt. URL: https://scorecompute.com/demos/get-network-job/ Supply a job_id returned by submit_network_job to inspect verified progress, completion or expiry for that public experiment. Use an actual returned ID: The example intentionally leaves job_id empty. First submit a real job, then paste its returned UUID; this page does not invent a ticket. Inspect the state: The receipt separates queued, running, completed and expired work, with checked chunk and sample counts. Read the final estimate when present: Only a completed job contains a final estimate. The contributor count and coordinator verification time remain visible. Example arguments: {"job_id":""} Limitations: - A valid existing job UUID is required before this example can run. - Public receipts contain only synthetic parameters. Old terminal receipts may be pruned and return not found. - A partial or expired job is not a completed calculation. Previously accepted samples do not guarantee that the remaining work will finish.