`_build_input_schema` misclassifies properties-less JSON Schemas as param mappings, breaking no-arg tools

Abierto Apto para principiantes
#1,509 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
74/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
python
Área
api

Línea de trabajo

Empieza en _build_input_schema en src/claude_agent_sdk/init.py (alrededor de las líneas 439-453), donde un dict sin procesar solo se pasa tal cual si tiene tanto 'type' como 'properties'. Lee la prueba de passthrough existente, test_json_schema_constraints_are_enforced en tests/test_sdk_mcp_integration.py, y reproduce el caso con {"type": "object"} mediante create_sdk_mcp_server. Está listo cuando ese esquema se devuelve sin cambios, una llamada con {} ejecuta el handler, los mapeos de parámetros estilo dict con parámetros de tipo valor siguen construyéndose correctamente y las pruebas existentes pasan.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug

Summary

_build_input_schema recognizes a raw JSON Schema dict only when it has both 'type' and 'properties' keys. Any valid JSON Schema without 'properties' — e.g. {"type": "object"}, {"type": "object", "additionalProperties": false}, {"anyOf": [...]} — is silently reinterpreted as a dict-style param mapping: its schema keywords become required string-typed parameters, and every call with the intended arguments fails validation with a misleading error.

This is a correctness bug, not a security vulnerability: the schema dict comes from the developer's own tool definition.

Version

  • Repo: anthropics/claude-agent-sdk-python
  • Package: claude-agent-sdk 0.2.181
  • Commit: 22b8eb9c19adfa78759b79e22bd664a57843bb06 (main, 2026-11-12)

Location

src/claude_agent_sdk/__init__.py:439-453 (_build_input_schema):

if isinstance(tool_def.input_schema, dict):
    if (
        "type" in tool_def.input_schema
        and "properties" in tool_def.input_schema
        and isinstance(tool_def.input_schema["type"], str)
    ):
        return tool_def.input_schema
    properties = {
        param_name: _python_type_to_json_schema(param_type)
        for param_name, param_type in tool_def.input_schema.items()
    }
    return {
        "type": "object",
        "properties": properties,
        "required": list(properties.keys()),
    }

For {"type": "object"}, _python_type_to_json_schema("object") falls through every branch (:381-413) to the default {"type": "string"} at :415, yielding properties: {"type": {"type": "string"}} with required: ["type"].

The tool() docstring promises input_schema may be "A JSON Schema dictionary for full validation" (:294-298) with no properties requirement, and test_json_schema_constraints_are_enforced (tests/test_sdk_mcp_integration.py:999-1017) establishes raw-schema passthrough as intended behavior for the type+properties shape. No test or doc states properties-less schemas are unsupported. ({} remains a working no-arg form — docstring :334 — which does not disprove misclassification of the canonical {"type": "object"} schema.)

The trigger chain: create_sdk_mcp_server builds the bogus schema (:606), run_tool validates with jsonschema.validate (:630) and returns an "Input validation error" (:631-632).

Minimal repro

import asyncio
from claude_agent_sdk import tool, create_sdk_mcp_server

@tool("t", "intended no-arg tool", {"type": "object"})
async def t(args):
    return "t-ran"

server = create_sdk_mcp_server("srv", tools=[t])
# tools/list advertises the schema, and tools/call "t" with {} fails:
#   Input validation error: 'type' is a required property

Schema-level demonstration of the misclassification:

# _build_input_schema({"type": "object"}) produces:
{"type": "object", "properties": {"type": {"type": "string"}}, "required": ["type"]}
# jsonschema.validate({}, <that schema>) raises:
#   ValidationError: 'type' is a required property

The same misclassification applies to {"type": "object", "additionalProperties": false} (keywords become required params type and additionalProperties) and {"anyOf": [...]} (anyOf becomes a required string parameter).

Observed: the advertised wire schema is the bogus rebuilt schema, and a live call with {} through the real run_tool closure and the real jsonschema package is rejected with 'type' is a required property.

Expected: {"type": "object"} passes through verbatim as the tool's input schema, and a call with {} runs the handler.

Impact

Developers who declare tools with the canonical no-argument JSON Schema {"type": "object"} (or any properties-less schema) get a tool that rejects every intended call with a misleading error demanding a bogus parameter — while the schema the tool advertises on the wire is wrong. The failure is silent at definition time and only surfaces at call time. Local functional impact only.

Suggested fix

Broaden the raw-schema recognition in _build_input_schema to accept dicts carrying JSON Schema keywords — e.g. 'type' with a string value, or 'anyOf' / 'allOf' / 'oneOf' / '$ref' / 'additionalProperties' — even without 'properties', returning them verbatim instead of rebuilding them as param mappings. (Note the known ambiguity: a dict-style param literally named "type" with a string value would need care; the dict-style form with type-valued params should keep building as a param mapping.)

Environment

  • Python 3.12.3, Linux; jsonschema 4.10.3 (real package; the SDK declares >=4.20.0, but the required-property rejection exercised here is stable across these versions, and the misclassification is visible in the produced schema dict independently of the validator)
  • Verified against the pinned commit above. Baseline: a type+properties raw schema passes through verbatim; dict-style {"name": str} builds a correct param schema and the live call succeeds; {} builds an empty-properties schema and the live no-arg call succeeds. The live call was exercised on the MCP 1.x server path; the defect is in _build_input_schema, which both majors consume, and the bogus schema is demonstrated directly from that function as well as via the wire listing.
Lenguaje dominante
Python
Estrellas
8.5k
Forks
1.4k
Merge medio
3 d 10 h
PR fusionados (30 d)
13

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de anthropics/claude-agent-sdk-python

Todos los issues de anthropics/claude-agent-sdk-python

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.