codecalc

Overview Schema Source Related Servers Discussions Admin

Bits

bits

Read-onlyIdempotent

Analyze integers: compute popcount, bit length, trailing zeros, power-of-two checks; perform AND/OR/XOR/shift/rotate operations; convert bases; identify which machine widths hold a value.

Instructions

Programmer-mode integer facts and operations, selected by mode — replaces the four former standalone tools bit_analysis, bitop, int_widths and base_repr, retired in 0.12.0 (CHANGELOG.md). Every mode returns exactly its former tool's own result, plus mode (additive).

mode="analysis" (was bit_analysis) — facts about a single N: popcount, bit length, trailing zeros, power-of-two check, next power of two. Used by this mode: n (required), align (optional).

mode="op" (was bitop) — combine two integers a/b with and/or/xor/nand/nor/xnor/not/shl/shr/sar/rol/ror at a fixed width (8/16/32/64). Every result shows unsigned, signed (two's complement), hex, octal and binary. shr is logical (zero-fill); sar is arithmetic (sign-propagating) — 0x80 shr 1 = 0x40 (+64) but 0x80 sar 1 = 0xC0 (-64); rol/ror rotate bits around the width instead of shifting them out. A left shift that drops bits says OVERFLOW and shows the unbounded answer. Used by this mode: a, op (required), b (required unless op="not"), width (optional).

mode="widths" (was int_widths) — which widths (i8..i64/u8..u64) hold n, and the wrapped value where they do not; flags anything past 2^53 as unable to round-trip through a JS number or JSON float. Used by this mode: n (required).

mode="repr" (was base_repr) — hex/oct/bin of n; with width, two's complement and signed-overflow detection. Used by this mode: n (required), width (optional).

Input Schema

TableJSON Schema

Name	Required	Description
`a`	No	First operand for mode='op'; required by that mode
`b`	No	Second operand for mode='op'; required unless op='not'
`n`	No	The integer to inspect; required by modes 'analysis', 'widths', and 'repr'
`op`	No	Bit operation for mode='op': and/or/xor/nand/nor/xnor/not/shl/shr/sar/rol/ror
`mode`	Yes	Which fact/operation to compute: 'analysis', 'op', 'widths', or 'repr' (each has its own required params)
`align`	No	Alignment boundary for mode='analysis'; reports padding needed to reach it
`width`	No	Bit width for mode='op' (8/16/32/64, default 64) or mode='repr' (omit to skip width analysis)

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.12.0Sep 9, 2026

addedInput schema / properties / a / description

Added value: +"First operand for mode='op'; required by that mode"

addedInput schema / properties / align / description

Added value: +"Alignment boundary for mode='analysis'; reports padding needed to reach it"

addedInput schema / properties / b / description

Added value: +"Second operand for mode='op'; required unless op='not'"

addedInput schema / properties / mode / description

Added value: +"Which fact/operation to compute: 'analysis', 'op', 'widths', or 'repr' (each has its own required params)"

addedInput schema / properties / n / description

Added value: +"The integer to inspect; required by modes 'analysis', 'widths', and 'repr'"

addedInput schema / properties / op / description

Added value: +"Bit operation for mode='op': and/or/xor/nand/nor/xnor/not/shl/shr/sar/rol/ror"

addedInput schema / properties / width / description

Added value: +"Bit width for mode='op' (8/16/32/64, default 64) or mode='repr' (omit to skip width analysis)"

Addedv0.11.0Sep 9, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The description goes well beyond the readOnlyHint/idempotentHint/destructiveHint annotations. It discloses output shape ('plus mode'), result formats (unsigned/signed/two's complement/hex/octal/binary), shift semantics (logical shr vs arithmetic sar), overflow behavior, and the 2^53 round-trip caveat. It thoroughly explains observable behavior without contradicting the annotations.

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 long because the tool unions four former tools, but every sentence earns its place. It is front-loaded with the tool's purpose and follows a consistent mode-by-mode structure, closing with concise examples that clarify subtle shift behavior.

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?

For a seven-parameter, multi-mode tool, the description is complete. It identifies all modes, their former names, their relevant parameters, the output shape, overflow and wrapping behavior, and precision caveats. The output schema's presence plus these details cover what an agent actually needs to invoke it correctly.

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?

Although the schema already covers all parameters well, the description adds mode-dependent semantics: which parameters each mode requires, the acceptable widths (8/16/32/64 default 64), and the b-optional-when-op='not' exception. These constraints are not fully inferable from the schema alone, so the description adds real value.

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 exactly what the tool computes: programmer-mode integer facts and operations selected by mode, and it enumerates the four modes with concrete behaviors and their former tool names. This gives an agent a clear, discriminable purpose and distinguishes the tool from broader sibling tools like radix_convert or float_repr.

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?

Each mode is given a distinct use case and its own parameter requirements, which effectively tells the agent when to use mode='analysis', 'op', 'widths', or 'repr'. It does not, however, explicitly contrast the tool with sibling alternatives such as radix_convert or calc_exact, so it stops short of fully explicit when-to-use-when-not guidance.

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