Output schemas not documented. The source code shows input schemas (parameter definitions) but no tool description includes documented return types or output field structures. LLMs cannot plan downstream actions without knowing what fields to extract.

Brief descriptions (10-40 chars) lack context for tool selection. Example: 'RC4 stream cipher encryption/decryption' (33 chars) does not explain when to use it, what formats it accepts, or what happens on error.

Complex parameter types (tuples, arrays of tuples) not represented in JSON Schema. Tools like elliptic_curve_point_add use tuple notation ('curve': {'type': 'tuple'}) which is invalid JSON Schema. Should be {'type': 'array', 'items': {'type': 'number'}, 'minItems': 3, 'maxItems': 3}. LLMs cannot parse non-standard schemas.

No error recovery guidance. Tools like factor_integer and discrete_log may fail, timeout, or require SageMath, but descriptions do not explain error conditions, when to retry, or what to try next. Per pattern:recovery-guide, errors should tell LLMs what to do.

Optional parameters lack descriptions in some tools. Example: factor_integer has prefer_yafu and timeout but their descriptions are minimal ('Prefer using yafu tool if available', 'Timeout in seconds for external tools'). No guidance on what happens if timeout is exceeded or yafu is not available.

No permission declarations or security scopes. Tools like factor_integer and coppersmith_attack may be computationally expensive and should declare resource requirements or scope limits, but none are present.

No idempotency guarantees. Tools like xor_single_break, rot_all, and detect_encoding are read-only and thus idempotent, but this is not declared via tool annotations. MCP tool annotations (readOnlyHint) would clarify safety for agents.