Provides integration with Kaggle as a compute worker for the GPU pool, allowing agents to submit jobs, track execution, and collect artifacts and metrics from Kaggle kernels.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@agent-gpu-pool Submit a training job to a suitable GPU and track its progress."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Give your AI agent a persistent compute queue—not another notebook to babysit.
中文说明 · Quick start · Kaggle setup · Architecture
Agent GPU Pool is a local, persistent compute broker for Codex, Claude Code, and MCP clients. Your agent describes a job's requirements; the broker selects an eligible worker, tracks execution, and collects results. A fresh agent session can discover those results without repeating the experiment.
Codex / Claude Code / MCP client
│ submit → job ID
▼
Persistent broker + hardware-aware scheduler
│
┌────────┼─────────┐
▼ ▼ ▼
Kaggle Local Fake demo
└────────┼─────────┘
▼
Artifacts + metrics + SHA-256 manifest
│
▼
Resume from another agent sessionA chat session should not be the only place that remembers an experiment. GPU access also varies: a worker with two small cards cannot serve a job requiring one large-memory card.
Recover across sessions. SQLite stores jobs, remote IDs, reservations, and results. A detached broker continues after the MCP client disconnects.
Match real hardware requirements. Filter by model, device count, and memory per device. Hardware options share their worker's quota and concurrency limit.
Preserve scarce capacity. Prefer a sufficient worker while leaving more flexible hardware available for demanding jobs, when other ranking criteria are equal.
Collect evidence. Artifacts have manifests and verified hashes. Execution success and scientific conclusions are separate records.
Avoid accidental duplicate runs. Persist identity before dispatch; reconcile ambiguous launches instead of blindly submitting again.
Use one interface. A CLI and 13 MCP tools share the same broker state. Credentials live in the OS keyring.
Related MCP server: clausius
Requires macOS or Linux, Python 3.11+, and uv.
git clone https://github.com/HarrisonYangKuang/agent-gpu-pool.git
cd agent-gpu-pool
uv sync --extra dev
source .venv/bin/activate
gpupool --home "$PWD/.demo-pool" demo
gpupool --home "$PWD/.demo-pool" jobsThis runs a synthetic demo, with no Kaggle account, GPU allocation, or paid cloud resource. It exercises the real scheduler, persistence, and artifact flow. A worker with 4 hours cannot take the simulated 8-hour job; the scheduler selects an eligible worker instead. Metrics marked synthetic: true are not training results. Use a fresh demo directory when repeating it.
With the virtual environment activated:
gpupool agent install codex
# Or:
gpupool agent install claudeEach command prints an installation command with your absolute executable and state paths. Run the printed command, then start a new agent session. Clients must use the same broker home to share jobs and results. Default: ~/.local/share/agent-gpu-pool.
Try asking your agent:
Inspect the GPU pool and check for finished results for my project before proposing another run. Use the broker to choose hardware that meets the job requirements.
MCP makes the tools available; the client must load the server, and the agent must choose to use them. Copy the relevant workflow from AGENTS.md or CLAUDE.md into your project instructions.
Install the optional adapter dependency and authenticate locally:
uv sync --extra dev --extra kaggle
gpupool credential add kaggle --name kaggle-main --oauth
gpupool credential test kaggle-mainThen register a worker and authorize a project. New projects permit only fake workers; real uploads and execution require an administrator-applied policy. Register only resources and sources you are permitted to use. Never paste tokens into chats or commit credentials.
Hardware configuration explains multiple options per worker. Example templates are unverified by default: they do not grant or establish provider access.
gpupool pool
gpupool jobs
gpupool job JOB_ID
gpupool logs JOB_ID --tail 50
gpupool artifacts JOB_ID
gpupool fetch JOB_ID metrics.json --contentSUCCEEDED means the program exited successfully. artifacts_ready separately indicates that required results were collected. Missing metrics trigger collection retries, not another training run.
Early release, not a claim of production readiness. The development suite contains 50 tests covering scheduling, quota reservations, restarts, real stdio MCP connections, client disconnects, local execution, artifacts, credential isolation, and mocked Kaggle CLI behavior.
Backend | Status |
Fake | End-to-end synthetic scheduling and artifact flow tested |
Local | Trusted Python execution; timeout and cancellation tested |
Kaggle | CLI adapter implemented; authentication/quota reads checked during development; broker-driven GPU launch and collection remain unverified on real hardware |
SSH / RunPod / Vast | Disabled extension placeholders |
POSIX process locks are required; Windows execution is not supported.
This is a trusted single-user service, not a code sandbox or multi-tenant platform.
Kaggle cancellation cannot safely stop a kernel through the checked CLI interface; the broker records the request and directs the user to the provider UI.
Hardware access is administrator-attested. Provider availability, competition permissions, and runtime compatibility may change.
Broker-owned reservations do not constitute a complete inventory of externally launched jobs.
Source snapshots use an explicit allowlist capped at 20 MiB. Large datasets should use provider sources.
Hash checking and read-only files provide application-level integrity, not tamper-proof storage.
No leaderboard submission, paid provisioning, or automatic training-script parallelization.
uv run pytest -q
uv run ruff check src testsUseful next steps include real Kaggle integration evidence, clearer first-run onboarding, and provider adapters with reliable reconciliation. See CONTRIBUTING.md and the security model.
If this solves a workflow you recognize, a star helps others find it. Bug reports and reproducible examples are especially welcome.
MIT licensed. Independent project; not affiliated with OpenAI, Anthropic, Kaggle, or NVIDIA.
Request cancellation; status changes only when confirmed by the worker.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It effectively communicates that cancellation is not immediate and that the job status changes only after worker confirmation, which is a key non-obvious behavioral trait. It does not cover error cases or idempotency, but the most important caveat is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, lean sentence that front-loads the action and immediately follows it with the critical asynchronous caveat. Every word adds value, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema and no annotations, the description covers the essential invocation context and the crucial post-condition behavior. It lacks return value details and edge-case behavior, but the simplicity of the tool and the explicit async warning make it reasonably complete for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explicitly define job_id or its format. The parameter name and title are self-explanatory, and the description loosely implies that job_id identifies the job to cancel, but the description does not compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Request cancellation') and the async nature of the operation ('status changes only when confirmed by the worker'). While it does not explicitly mention 'job', the tool name and job_id parameter make the resource unambiguous. It distinguishes itself from read-only sibling tools by describing a cancellation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use cancel_job versus alternatives, nor are there any prerequisites or exclusions. The description implies it should be used when a previously submitted job needs cancellation, but this is left to inference rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify artifact hash and return its local path; content requires explicit true and is bounded.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| job_id | Yes | ||
| content | No | ||
| max_bytes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It usefully reveals that the tool verifies the artifact hash, returns a local path, and only returns content when explicitly requested and bounded. However, it does not clarify what happens on hash mismatch, how 'bounded' is enforced, or whether network/IO side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence with no fluff, and the primary purpose is front-loaded. The second clause is terse and somewhat ambiguous, but it still conveys the key content-related constraint without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and zero parameter descriptions, the description is too sparse. It gives the return type (local path) and a hint about content, but it omits selection criteria, artifact identification semantics, failure behavior, and precise limits, leaving the agent to infer too much.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It adds some meaning for content and max_bytes ('content requires explicit true and is bounded'), but it does not explain how job_id and name identify the artifact, nor what units or limits max_bytes uses.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific action—'Verify artifact hash and return its local path'—and a clear resource (artifact). It stops short of explicitly naming a sibling alternative like list_artifacts, but the verify-and-return-path wording differentiates it from listing operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use fetch_artifact versus list_artifacts or other job-related tools. The only usage hint is that content requires explicit true and is bounded, which is more of a parameter behavior than tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recover durable job state across agent sessions and broker restarts.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Recover durable job state' suggests reading persistent state, but it does not clarify whether this is a pure read, whether it has any side effects, what state fields are returned, or how it behaves when the job does not exist. The term 'recover' is ambiguous about whether the tool actively restores state or simply retrieves it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler, which is concise. However, it is more under-specified than genuinely helpful: the phrase 'Recover durable job state' is cryptic and does not clearly communicate the tool's basic function to an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description leaves important gaps: it does not explain what the returned state looks like, how to distinguish this tool from list_jobs, or what the expected behavior is for missing or invalid job_ids. The lack of any output schema makes this omission more significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, job_id, with no description coverage (0%). The description does not mention job_id at all, nor does it explain what values are expected, how to obtain a valid job_id, or how the parameter relates to the 'durable job state' being recovered. The tool description adds no value beyond the raw schema property name and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Recover') and resource ('durable job state'), and the phrase 'across agent sessions and broker restarts' gives it a distinct scope from the sibling tools like list_jobs and get_job_logs. It does not explicitly differentiate itself from those siblings by name, but the intent is reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when resuming work after a session or broker restart, which provides some usage context. However, it gives no explicit guidance on when to use get_job versus list_jobs, get_job_logs, or cancel_job, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bounded logs; offset counts backwards from the end of the available log window.
| Name | Required | Description | Default |
|---|---|---|---|
| tail | No | ||
| job_id | Yes | ||
| offset | No | ||
| search | No | ||
| error_only | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does add a non-obvious behavioral trait: logs are bounded, and offset counts backwards from the end of the available log window. However, it does not explain limits, filter behavior, output format, or failure modes, so coverage is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loads the bounded-logs constraint, which is efficient. However, it is so terse that it borders on under-specification for a tool with five parameters and no other documentation, so it is adequate but not exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, no annotations, and five parameters, yet the description does not mention the required job_id, the meaning of tail, search, error_only, log content, or return behavior. 'Bounded logs' is a useful hint but far from sufficient for an agent to invoke this tool correctly in varied situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the five parameters. It only clarifies the semantics of offset; job_id, tail, search, and error_only are left without any added meaning. Since the schema provides only titles and types, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Bounded logs' and refers to a log window, so an agent can infer this tool deals with logs, but it never explicitly states the action of retrieving/getting logs for a job. It also does not differentiate itself from siblings such as get_job or list_jobs; an agent must rely on the tool name to understand the primary purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus get_job, list_jobs, or fetch_artifact. The phrase 'Bounded logs' hints at scoping but does not explain when this tool is appropriate, what alternatives exist, or what conditions should route an agent to another sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return runs and recorded conclusions for a project.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| project | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly states a retrieval behavior ('Return'), which suggests a read-only operation, but it does not disclose pagination behavior, ordering, or any assumptions about the project parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and resource. There is no filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema likely covers return-value structure, and the basic purpose is stated. However, the description is thin: it omits pagination semantics, gives no usage guidance, and relies heavily on the tool name and parameter defaults to convey context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description only clarifies the 'project' parameter by saying 'for a project.' It adds no meaning for 'limit' or 'offset', leaving their semantics to inference from the parameter names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Return' and names the resource 'runs and recorded conclusions' scoped to a project. It is clear about what the tool does, but it does not explicitly differentiate it from sibling tools like list_jobs or list_ready_results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as get_job, list_jobs, or list_ready_results. There are no exclusions, prerequisites, or alternative conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return canonical paths, sizes, and hashes before reading content.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It clearly indicates that the tool returns metadata rather than content, implying a read-only listing. It does not disclose output format, failure behavior, or side effects, but for a simple list operation this is minimally acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no filler. It front-loads the return values and adds the useful 'before reading content' qualifier without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter metadata-list tool, the description covers what is returned but omits job scoping, output shape, and potential limitations. It is adequate for a simple call but leaves the agent to rely on the schema for parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning, but it never mentions the required job_id parameter or explains that artifacts are scoped to a specific job. The agent is left to infer how job_id relates to the returned paths, sizes, and hashes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Return') on the artifacts resource and lists the exact metadata returned: canonical paths, sizes, and hashes. It does not explicitly name sibling alternatives, but 'before reading content' hints at the distinction from fetch_artifact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before reading content' implies when to use this tool and suggests it should precede content-reading operations. However, it does not explicitly say when not to use it or name alternative tools such as fetch_artifact.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List persistent jobs with pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| status | No | ||
| project | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it offers only two behavioral hints: the operation is a read ('List') and results are paginated. It does not explain what qualifies a job as 'persistent', whether results are ordered, or how filters behave. The unexplained 'persistent' qualifier raises more questions than the description answers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence of five words with no filler: the verb, resource, and pagination mechanism are all present. It borders on under-specification by omitting filter semantics, but as written it is genuinely tight and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return shape, but the description leaves three gaps for a tool with no annotations: 'persistent' is undefined, status/project filters have no semantics (0% schema coverage), and there is no routing guidance among 12 siblings. An agent can invoke it safely with defaults but cannot use it correctly for filtered lookups.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description was expected to compensate, but it covers only pagination (which gives limit/offset meaning) and says nothing about status or project. Valid status values, whether filters are exact-match, and how filters combine with pagination are all unexplained. With 0% coverage, the description needed to address every parameter and did not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('List persistent jobs') and names the pagination mode, which distinguishes the tool from single-item siblings like get_job and non-job resources like list_artifacts. However, it does not explicitly differentiate from the overlapping-sounding list_ready_results or get_project_runs, and the qualifier 'persistent' is left undefined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance or alternative routing is given. The description names none of the 12 siblings and states no conditions, prerequisites, or exclusions, so the only usage signal is the implied action of listing. An agent cannot tell from the description whether list_jobs or list_ready_results is the right entry point for a given request.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover finalized results from earlier sessions; check status before interpreting.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| project | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does convey that only finalized/completed results are returned ('finalized results') and that it is a read-style discovery operation, but it does not mention side effects, permissions, pagination behavior, or time-based scoping beyond 'earlier sessions'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It states the core purpose first and then adds a practical usage hint. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values are presumably documented elsewhere. However, the description does not mention pagination, filtering behavior, or that all parameters are optional, and with no annotations the safety profile is unknown. For a simple list tool with three optional parameters, this is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the parameters. It does not mention limit, offset, or project at all. While the parameter names are somewhat self-explanatory, the description adds no meaning beyond the schema's titles and defaults, leaving the agent to infer semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Discover' with a specific resource 'finalized results from earlier sessions', and adds a purpose hint with 'check status before interpreting'. It does not explicitly differentiate from sibling tools because no siblings are named, but the core action and target are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'check status before interpreting' implies that this tool should be used as a preliminary step before analyzing results, which is a useful contextual cue. However, there is no explicit mention of when to use this tool versus alternatives, nor any exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List normalized worker capabilities without credential profiles.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It usefully states that the output is normalized and excludes credential profiles, and 'List' implies a read operation. It does not mention any potential side effects or access requirements, but for a simple listing tool this is a reasonable level of disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly constructed sentence that front-loads the core action and resource while adding the key qualifier ('without credential profiles'). No words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool with an output schema, the description is nearly complete. It explains the tool's purpose and a key behavioral boundary, and the output schema covers return values. More explicit guidance about when to choose this over sibling tools would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema reflects this with an empty properties object. The baseline for zero-parameter tools is 4, and the description does not need to explain any parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb ('List'), a clear resource ('worker capabilities'), and a scope qualifier ('normalized', 'without credential profiles'). It is immediately distinguishable from the sibling tools, all of which concern jobs, artifacts, quotas, or results rather than workers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need normalized worker capabilities and do not need credential profiles. However, it does not explicitly state alternatives or provide exclusion criteria relative to the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show worker capacities separately and durable job counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavior disclosure. The verb 'Show' implies a non-mutating read, but the description does not state whether this is read-only, how the counts are scoped, or what the response format looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler and gets straight to the point. It is appropriately short for a parameterless tool, though 'separately' could be clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero parameters, no output schema, and no annotations, the definition is minimal but adequate for a basic overview. It would benefit from a note on when to prefer this over list_workers or list_jobs, and from clarifying what 'durable job counts' means in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description has no parameter semantics to add. The baseline for zero-parameter tools is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Show') and names the core output concepts ('worker capacities', 'durable job counts'). It implies an aggregated overview distinct from the sibling listing tools, though the word 'separately' adds slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives like list_workers or list_jobs. There is no explicit use case, prerequisite, or distinction from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Attach scientific interpretation separately from immutable infrastructure artifacts.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| decision | Yes | ||
| conclusion | Yes | ||
| new_metric | Yes | ||
| baseline_metric | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It implies a write operation ('Attach') but does not state whether this creates, updates, or mutates anything, what side effects occur, whether it is destructive, or what the return behavior is. The phrase 'immutable infrastructure artifacts' hints at separation but does not explain actual tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but brevity is not conciseness when it delivers almost no information. The single sentence is front-loaded but vague, and every word fails to add operational value. It is under-specified rather than efficiently specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 5 required parameters, no output schema, no annotations, and no parameter documentation, yet the description explains none of the inputs, outcomes, or constraints. An agent has essentially no basis for correct invocation. This is completely inadequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning about any of the five parameters. Terms like 'scientific interpretation' might loosely map to conclusion/decision, but the description never explains job_id, baseline_metric, new_metric, decision, or conclusion. With no parameter documentation, an agent cannot reliably populate the required inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Attach scientific interpretation separately from immutable infrastructure artifacts' is metaphorical and vague. It does not clearly state that this tool records an experiment result, nor does it mention the metrics, decision, or conclusion that the schema shows are central. It also does not distinguish itself from siblings like list_ready_results or submit_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as submit_job or list_ready_results. No context, prerequisites, or exclusions are provided. The only hint is that it relates to scientific interpretation, but this is not actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Persist an experiment and return its job ID quickly; existing project policy controls dispatch.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | ||
| idempotency_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds a small insight that dispatch is policy-controlled and that the response is quick, but it omits side effects, idempotency behavior, permission requirements, and whether the job is guaranteed to execute.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that communicates the primary action and return value efficiently. The trailing policy clause is somewhat vague but does not add unnecessary bulk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex nested spec, an idempotency key parameter, no output schema, and no annotations. This minimal description does not give an agent enough context to construct a valid request or understand the job submission lifecycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description mentions neither 'spec' nor 'idempotency_key'. The nested JobSpec with many properties is left entirely to schema names and defaults, so the description adds no parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action ('Persist an experiment') and a clear return value ('return its job ID'), which distinguishes it from job retrieval and cancellation siblings. It does not explicitly name an alternative, so it falls short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use submit_job versus get_job, cancel_job, or record_experiment_result. The phrase 'existing project policy controls dispatch' hints at behavior but does not explain selection criteria or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refresh authoritative provider quotas; unknown is not zero.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavior itself. It offers a useful semantic caveat—'unknown is not zero'—and clarifies the source is authoritative. However, it doesn't say whether sync is destructive, requires credentials, or what state is affected, so transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clauses, no filler; the action is front-loaded and the caveat is appended. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, little is needed to construct a valid call, and the output schema covers return values. However, the description leaves open when to call it and what 'refresh' implies for existing state, which are meaningful gaps for an agent deciding to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters, so there is nothing for the description to document. Baseline 4 applies because no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Refresh') and resource ('authoritative provider quotas'), so an agent can understand the operation. It doesn't explicitly differentiate from siblings, but none of the siblings concern quota syncing, so no confusion arises.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to invoke this tool versus alternatives, or whether it should be run before other quota-dependent operations. The only contextual clue is the word 'Refresh', but the description never states when it is needed or what prerequisites exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0cancel_jobfetch_artifactget_jobget_job_logsget_project_runslist_artifactslist_jobslist_ready_resultslist_workerspool_overviewrecord_experiment_resultsubmit_jobsync_quotasMost tools target a distinct resource and action, making selection straightforward. The only mild overlap is list_workers versus pool_overview, which both expose capacity-like information, but their differing focus on individual workers versus aggregate pool state keeps them separable.
Twelve of thirteen tools consistently follow a verb_noun pattern such as list_workers, submit_job, and fetch_artifact. The outlier is pool_overview, which would fit better as get_pool_overview, but this is a minor deviation.
Thirteen tools is well-scoped for a GPU pool management server covering workers, quotas, jobs, logs, artifacts, and results. Each tool has a clear role without unnecessary redundancy or bloat.
The tool surface covers the core workflow well: submitting and tracking jobs, canceling them, retrieving logs, managing artifacts, and recording results. Minor gaps exist around directly querying quotas and updating/deleting job or result records, but these may be deliberate persistence constraints.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Agent-first task marketplace MCP — discover, claim, and deliver paid workspace tasks.
AI agent registry — search, discover, register, and connect agents via MCP.
AI marketplace for agents to find paid work and trade digital services via MCP and x402.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/HarrisonYangKuang/agent-gpu-pool'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
