Skip to main content
Glama
codeofaxel

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

kiln_spend_caps_request_change

Request a higher per-order or monthly spend cap for approval; returns a challenge ID so you can review current and requested caps, then confirm with an authenticator code.

Instructions

Ask to raise the per-order and/or monthly spend cap (step 1 of 2).

        The servers hold the requested change for a few minutes and
        return a ``challenge_id``.  Show the person ``current_caps`` and
        ``requested_caps`` so they can review the change, then ask them
        for the six-digit code from their authenticator app and pass it
        to ``kiln_spend_caps_confirm_change``.

        Args:
            per_order_dollars: New per-order cap; leave unset to keep it.
            monthly_dollars: New monthly cap; leave unset to keep it.
            reason: Optional note kept with the change.

        A refusal says which case it is (chat changes turned off, with
        ``enable_url``; too many attempts, with ``retry_after_seconds``;
        a cap below the minimum).  Relay it as written.

Input Schema

NameRequiredDescriptionDefault
reasonNo
monthly_dollarsNo
per_order_dollarsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses that the server holds the change for a few minutes, returns a challenge_id, and may refuse with case-specific details such as enable_url or retry_after_seconds that must be relayed as written.

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

Conciseness4/5

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

The description is front-loaded with the purpose and two-step flow, then gives parameter meanings and refusal behavior. It is information-dense with little waste, though the indented prose and Args formatting make it slightly less scannable than an ideal short definition.

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

Completeness5/5

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

Given no annotations and no parameter descriptions in the schema, the description supplies the workflow, parameter semantics, refusal cases, and the needed handoff to confirmation. Because an output schema exists, it need not further explain return fields, and nothing essential for correct invocation is missing.

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

Parameters5/5

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

Schema description coverage is 0%, but the description documents all three parameters: per_order_dollars and monthly_dollars set new caps and may be left unset to keep existing values, while reason is an optional note. This fully compensates for the schema’s lack of parameter descriptions.

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

Purpose5/5

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

The description states a specific action and resource: raising the per-order and/or monthly spend cap. It explicitly frames this as step 1 of 2 and names the confirmation sibling, so an agent can distinguish it from kiln_spend_caps_confirm_change.

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

Usage Guidelines4/5

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

It clearly explains the two-step flow and routes the agent to kiln_spend_caps_confirm_change after review and authenticator-code entry. It does not explicitly state when not to use this tool or how it differs from kiln_spend_caps_request_order_approval, but the context is otherwise clear.

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