agent-gpu-pool
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| pool_overviewB | Show worker capacities separately and durable job counts. |
| list_workersA | List normalized worker capabilities without credential profiles. |
| sync_quotasB | Refresh authoritative provider quotas; unknown is not zero. |
| submit_jobB | Persist an experiment and return its job ID quickly; existing project policy controls dispatch. |
| get_jobC | Recover durable job state across agent sessions and broker restarts. |
| retry_artifact_collectionB | Restart exhausted artifact retrieval only; never rerun the compute job. |
| list_jobsC | List persistent jobs with pagination. |
| cancel_jobB | Request cancellation; status changes only when confirmed by the worker. |
| get_job_logsC | Bounded logs; offset counts backwards from the end of the available log window. |
| list_ready_resultsB | Discover finalized results from earlier sessions; check status before interpreting. |
| list_artifactsB | Return canonical paths, sizes, and hashes before reading content. |
| fetch_artifactC | Verify artifact hash and return its local path; content requires explicit true and is bounded. |
| record_experiment_resultD | Attach scientific interpretation separately from immutable infrastructure artifacts. |
| get_project_runsB | Return runs and recorded conclusions for a project. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 14 tools
Each tool targets a distinct operation or resource, with clear separation between job management (submit, get, list, cancel, logs), artifact handling (fetch, retry, list), experiment records, and infrastructure overview (pool, workers, quotas). Even similar-sounding tools like list_jobs and list_ready_results are clearly differentiated by their purpose and description.
All tool names follow a consistent verb_noun pattern (e.g., submit_job, list_jobs, cancel_job, fetch_artifact, sync_quotas). The verbs are clear and uniform across the set, making it easy to predict the action of each tool from its name.
With 14 tools covering job lifecycle, artifact management, experiment recording, and cluster monitoring, the count feels well-scoped for a scientific computing MCP server. Each tool serves a distinct purpose without redundancy, and the number is within the ideal range for maintainability.
The tool set covers the full lifecycle: job submission, retrieval, listing, cancellation, logs; artifact collection, retrieval, and listing; experiment result recording and project runs; and infrastructure monitoring like worker lists and quota sync. This is a complete surface for managing computational experiments on a GPU pool.