CountBean

await_device_approval

Wait for a user to approve a device authorization code, then save the connection and switch all accounting tools to that book. Blocks until approval, decline, or expiry.

Instructions

Step 2: wait for the user to approve the code from start_device_authorization.

Blocks until they approve, decline, or the code expires. On success the connection is saved and every countbean tool switches to that book.

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": "await_device_approval"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 5, 2026

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by stating that the tool blocks until approval, decline, or expiration, and that success saves the connection and switches all countbean tools to that book. This gives the agent a clear model of the side effects and waiting semantics.

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?

The description is highly concise: two short sentences, front-loaded with the step sequence and ending with the key side effect. Every sentence earns its place without redundant or generic filler.

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 the tool's zero-parameter interface and the availability of an output schema, the description is complete. It explains what triggers the wait, what it blocks on, and what happens on success, which is all an agent needs to safely invoke this tool in the correct flow position.

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?

The tool has zero parameters and the schema is empty with 100% description coverage, so the baseline of 4 applies. The description adds context about the originating code from `start_device_authorization`, but no parameter documentation is needed because none exist.

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 clearly identifies the tool as 'Step 2' in a device authorization flow: waiting for user approval of a code from `start_device_authorization`. This distinguishes it from siblings like `start_device_authorization` (which initiates the flow) and `connect_book` (which may establish a connection by other means).

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?

The description explicitly places the tool in sequence ('Step 2') and references `start_device_authorization` as the prerequisite, giving clear usage context. It describes the blocking wait and post-success behavior, but it does not explicitly state when to avoid this tool or name alternative connection methods.

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