MCP · agents

Utiliser VoxelBench depuis votre agent

Un point d'accès, les outils de l'API, et un diagnostic déjà calculé. Votre agent lit des mesures et s'occupe de vos serveurs — il ne produit jamais de mesure, et ne supprime jamais rien.

Créer un jeton d'APIRéférence de l'APIllms.txt
Claude Code — une commande

Ajoutez le serveur — sans créer de jeton :

bash
claude mcp add --transport http voxelbench https://voxelbench.com/api/v1/mcp

Tapez ensuite /mcp dans Claude Code, choisissez voxelbench puis Authenticate. Votre navigateur ouvre la même page de consentement que Claude Web : vous approuvez exactement ce qu'il pourra lire et modifier, et Claude Code renouvelle son accès tout seul.

Pour les scripts et la CI, où personne n'est là pour cliquer

Créez un jeton en ne cochant que les portées nécessaires, puis lancez ceci. Le jeton voyage à chaque requête ; rien n'est stocké chez nous.

bash
claude mcp add --transport http voxelbench https://voxelbench.com/api/v1/mcp \
  --header "Authorization: Bearer vb_your_token"

Ou écrivez-le vous-même, dans .mcp.json pour le projet ou ~/.claude.json pour votre compte :

.mcp.json
{
  "mcpServers": {
    "voxelbench": {
      "type": "http",
      "url": "https://voxelbench.com/api/v1/mcp",
      "headers": { "Authorization": "Bearer vb_your_token" }
    }
  }
}

Votre agent voit alors ce que voit votre compte : vos rapports privés, vos serveurs, vos bancs.

Claude Web et Desktop — un connecteur personnalisé

Paramètres → Connecteurs → Ajouter un connecteur personnalisé, puis collez cette URL. Claude vous demandera de vous connecter et d'approuver ce qu'il pourra lire et modifier — aucun jeton à recopier.

URL
https://voxelbench.com/api/v1/mcp

C'est vous qui l'autorisez, à l'écran

Le formulaire de connecteur ne prend qu'une URL : le serveur répond donc par un défi d'autorisation, et Claude ouvre une page VoxelBench qui nomme l'application, l'adresse où elle vous renverra, et ce qu'elle demande exactement. Vous autorisez, et il lit vos propres données — rapports privés compris. L'autorisation occupe un des jetons d'API de votre plan et figure à côté d'eux, révocable quand vous voulez.

Ce que votre agent sait faire

Cette liste est le catalogue du serveur lui-même — les outils que tout compte peut utiliser, chargés par les deux transports, donc elle ne peut pas diverger de ce qui est réellement servi.

  • list_reports

    Lists readable benchmark reports.

  • get_report

    A full report: scores, sub-scores, multipliers, hardware.

  • compare_servers

    Compares two benchmark reports - one report is one measurement of one server - and returns a verdict that is ALREADY COMPUTED server-side.

  • get_report_diagnosis

    Named findings for a report: what its measurements imply, each with a severity, the test concerned, a cause code when the payload settles one, and the numbers that produced it.

  • list_unit_tests

    Lists unit tests.

  • get_unit_test

    A full unit test: percentiles, test-specific metrics, parameters, and for a tier run the rung-by-rung progression.

  • list_servers

    Linked servers, with their verification state.

  • list_auto_bench_targets

    The bearer's auto-bench targets.

  • list_auto_bench_jobs

    Runs of the bearer's targets.

  • run_auto_bench_now

    Triggers a run on an EXISTING target.

  • cancel_auto_bench_job

    Asks a run to stop.

  • update_server

    Renames a linked server or changes its visibility settings: name, is_public, show_address_on_report, notify_on_report.

  • link_server

    Links a NEW Minecraft server to the account, using the 8-character code the VoxelBench plugin prints in the server console (/bench link).

  • list_server_groups

    The account's server groups (20 at most).

  • create_server_group

    Creates a server group.

  • update_server_group

    Renames, recolours or reorders a server group.

  • set_server_group

    Sorts a server into a group, or takes it out with group_id: null.

  • update_report

    Changes a report's visibility, description or private notes.

  • list_alert_rules

    The monitoring alert rules of one of the bearer's servers.

  • create_alert_rule

    Creates a monitoring alert rule on a server: fire when metric is below/above threshold for duration_minutes.

  • update_alert_rule

    Edits an alert rule, or pauses it with enabled: false.

  • get_maintenance

    Whether one of the bearer's servers is in a maintenance window, until when and why.

  • start_maintenance

    Starts a maintenance window on one of the bearer's servers for duration_minutes (REQUIRED, 5 to 1440): every alert of the server keeps being evaluated and recorded, but nobody is notified until the window ends - use it before a planned restart, an update or any work that would trip the alerts.

  • end_maintenance

    Ends the maintenance window in progress on one of the bearer's servers: its alerts are notified again from the next evaluation (within a minute).

  • list_alert_events

    Alerts the bearer's rules raised, most recent first, from BOTH families: threshold rules (kind: threshold) and event rules (kind: event, e.g.

  • list_event_alert_rules

    The event alert rules of one of the bearer's servers, read-only: what event type, category, source and minimum severity each one matches, and on which channels it notifies.

  • test_alert_rule

    Sends a TEST notification for a threshold alert rule now, on the channels the rule notifies (in-app, email, the server's Discord webhook, the owner's personal Discord), prefixed with [TEST], and returns what each channel did (delivery).

  • acknowledge_alert

    Acknowledges a triggered alert: marks it seen and stops it from being notified again.

  • update_auto_bench_target

    Reschedules an EXISTING auto-bench target: enabled (false pauses it), schedule_cron (five-field cron evaluated in UTC, at most once per hour - schedule_too_frequent otherwise), name, notes.

  • get_server_status

    Live status of one of the bearer's servers (owned_by_you: true; another account's server answers not_owner).

  • get_server_regression

    Whether a verified server's benchmark performance has dropped - the verdict the platform's regression alert computes, ALREADY DECIDED: quote it, do not recompute it.

  • get_monitoring_overview

    The state of ALL the bearer's monitored servers in ONE call - use it instead of calling get_server_status once per server, which spends quota for each.

  • get_server_metrics

    Time series of one of the bearer's servers (owned_by_you: true; another account's server answers not_owner) - the same data the dashboard charts.

  • list_server_events

    The timeline of one of the bearer's servers (owned_by_you: true; another account's server answers not_owner), most recent first: starts, stops and restarts, benchmark runs, moderation actions, alerts raised by third-party plugins.

  • get_profile_history

    The performance-profile history of one of the bearer's servers (owned_by_you: true; another account's server answers not_owner): one summary per profile the server sent, most recent upload first - who used the tick (owners, plugins included, self_pct and total_pct), the busiest methods, a breakdown by kind of work (categories) and key_points.

  • get_profile

    One full performance profile of one of the bearer's servers (owned_by_you: true; another account's server answers not_owner), while the plan's limits still keep it: take profile_id from get_profile_history - null there means the profile is gone and only its summary is left (404 here).

  • compare_profiles

    What changed between two performance profiles of the same server of the bearer (owned_by_you: true): shares per owner, per kind of work (categories) and per method, key points that appeared or were resolved.

  • list_profiles

    The performance profiles of EVERY server the bearer owns, in one call, most recent upload first: one row per profile, read from its summary (kept a year) - server_id and server_name, trigger (manual, ring, lag), lag (kind, slow_ticks, longest_tick_ms), tick_samples, and top_plugin (the listed plugin with the largest own share of tick samples, with self_pct and total_pct).

  • list_memory_reports

    Memory reports, most recent upload first: heap summaries (kind heap-summary, the JVM class histogram per plugin, shallow sizes) and heap dump analyses (kind heap-analysis: quick = shallow sizes by class loader, full = retained sizes and leak suspects, retained = a targeted analysis of ONE plugin: what that plugin alone retains, plus the quick-pass sections).

  • get_memory_report

    One memory report of one of the bearer's servers (owned_by_you: true; another account's server answers not_owner), with a compact diagnosis: totals, memory per owner, leak suspects with their path from a GC root (path.steps, first step the root side; via is how the previous object holds the next, e.g.

  • compare_memory_reports

    Compares two memory reports of the SAME server of the bearer (owned_by_you: true; another account's server answers not_owner; a report of another server is not_found).

  • get_report_tuning

    Tuning advice computed from a report - exactly what its page shows.

  • compare_before_after

    Did a change improve a server? Give the report ids from BEFORE and AFTER the change, and the subtests it targeted.

  • list_offers

    Hosting offers with the evidence behind their performance: certified (hoster-approved, not expired), measured (VoxelBench ran the benchmark), linked (only associated), or none.

Quoi lui demander

Une fois branché, le langage courant suffit.

  • « Ouvre mon dernier rapport et dis-moi ce que ses mesures impliquent. »
  • « Compare ces deux rapports et dis-moi lequel l'emporte, et sur quoi. »
  • « Lance un banc sur ma cible auto-bench, puis préviens-moi quand le rapport est là. »
  • « Montre mes jobs auto-bench de la semaine et dis-moi lesquels ont échoué, et pourquoi. »
  • « Lie mon nouveau serveur avec le code K7PX2QMA, appelle-le Survie 1.21 et range-le dans mon groupe Production. »

Ce qui tient, quel que soit l'agent

  • • Chaque chiffre sort de la chaîne de mesure. Comparaisons et diagnostics sont calculés côté serveur et rendus déjà tranchés — le modèle les cite, il ne les recalcule pas.
  • • Une ressource que vous n'avez pas le droit de lire rend 404, jamais 403. Votre agent ne doit pas y lire « ça n'existe pas ».
  • • Un appel d'outil coûte une lecture. Le plafond journalier de votre plan s'applique par compte — pas par jeton, donc un second connecteur n'achète rien. Un run occupe sa cible : rejouer un lancement adopte le run déjà en vol au lieu d'en démarrer un second.
  • • Un jeton ne porte que les portées cochées, et jamais plus que ce que votre plan accorde aujourd'hui.