Skip to main content
Glama

bitpull_set_ai_limits

Set daily, weekly, or monthly caps on AI requests and tokens this computer handles for others; use null for no limit.

Instructions

Set how much AI work this computer does for others: maximum requests and tokens per day, week and month (null = no limit).

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_ai_limits"
  }
}

Input Schema

NameRequiredDescriptionDefault
dayNo
weekNo
monthNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

The annotation only declares destructiveHint=false, so the description must carry most of the behavioral burden. It adds a useful semantic rule (null = no limit) but does not say whether limits replace the whole configuration, whether omitted day/week/month values are preserved or cleared, or when changes take effect.

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?

A single front-loaded sentence that conveys the resource, the dimensions (requests/tokens per day/week/month), and the null convention with no filler.

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

Completeness3/5

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

For a low-complexity configuration tool with no output schema, the description covers the shape of the input and the null semantics adequately. However, with 0% schema coverage, it should also clarify partial-update behavior and any prerequisites (e.g., needing to be logged in or to have lending enabled).

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

Parameters4/5

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

Schema description coverage is 0% and the schema uses nested objects, yet the description names all three top-level periods (day, week, month) and both nested quantities (requests, tokens), and explains that null means unlimited. It still leaves ambiguity about whether each period object must include both fields and what happens to unset periods.

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?

The description states a specific verb and resource: setting limits on requests and tokens for AI work this computer performs for others, across day/week/month. It is clearly distinct from siblings such as bitpull_file_limits or bitpull_set_network, though it does not name them explicitly.

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?

Usage is implied by the phrase 'how much AI work this computer does for others,' which signals this is a lending/quota configuration tool. There is no explicit when-to-use or when-not-to-use guidance and no pointer to related siblings such as bitpull_set_lending_rules or bitpull_pause_lending.

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