Skip to main content
Glama
Sign In
BitPull

BitPull

by SamuealPK
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

bitpull_set_lending_rules

Configure which resources this computer lends, when lending is allowed, and how sandboxed jobs run; only supplied fields change, so confirm changes with the person first.

Instructions

Change what this computer lends and when. Only the fields given change. Turning lending on lets other people's jobs run here, sandboxed. Confirm with the person first.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "bitpull_set_lending_rules"
  }
}

Input Schema

NameRequiredDescriptionDefault
gpuNoGPU class lent, by video memory
hoursNoLend only between these hours, e.g. [22, 8]; null = any time
enabledNoMaster switch for lending
maxCpusNo
sandboxNo
onlyOnAcNoLend only when plugged in
keepAwakeNoKeep the computer from sleeping while it runs a job for someone; default on
containersNoRun container jobs (needs Docker or Apple Container)
cacheCopiesNoHow many public repos of others to keep a copy of
idleMinutesNoLend only after this many minutes without keyboard/mouse; 0 = always
maxMemoryMbNo
serveModelsNoServe the open AI models installed on this computer
answerWaitMinutesNoHow long to wait for answers from the network's AI models (default 10 minutes)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only supply destructiveHint=false, so the description must carry the rest, and it does disclose two non-obvious traits: the operation is a partial/patch update, and enabling lending lets other people's jobs run locally in a sandbox. The human-confirmation requirement is an important operational constraint absent from annotations. It stops short of saying whether changes apply to jobs already running or how to fully revert.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with the purpose, then partial-update semantics, then the consequential effect, then the safety rule. No filler and nothing buried.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter settings mutation with no required fields and no output schema, the description covers the essentials an agent needs: partial update, the meaning of enabling, and the need to confirm. Minor gaps remain around instant-apply behavior and how to disable previously enabled capabilities.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Coverage is 77%, so the schema already explains most fields, and the description only gestures at them ("fields", "turning lending on", "sandboxed"). Given this baseline a 3 is appropriate: it adds framing but no parameter-level detail such as what happens when a value is null or which settings interact.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Change what this computer lends and when" gives a specific verb and resource, and the scope word "Change" signals a settings mutation rather than an on/off toggle, which separates it from bitpull_pause_lending. It never names a sibling explicitly, so an agent must infer the boundary rather than read it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Confirm with the person first" is a real precondition, and "Only the fields given change" tells the agent this is a partial update so it should send just the deltas. There is no guidance on when to prefer bitpull_pause_lending over setting enabled=false, and no stated condition where this tool should not be used.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools