native tool schema: unsupported type for '${key}' (only stri

Error message

native tool schema: unsupported type for '${key}' (only string / string-enum / boolean)

What it means

jsonSchemaToTypeBox supports only three property kinds for Pi native tools: string, string-enum, and boolean. Any other property type (number, integer, array, object, missing type) throws this error listing the supported set.

Source

Thrown at packages/providers/src/community/pi/native-tools.ts:42

  const required = new Set(
    Array.isArray(schema.required) ? (schema.required as unknown[]).filter(isString) : []
  );

  const shape: Record<string, TSchema> = {};
  for (const [key, prop] of Object.entries(props)) {
    let field: TSchema;
    if (Array.isArray(prop.enum)) {
      const values = prop.enum.filter(isString);
      if (values.length === 0) {
        throw new Error(`native tool schema: enum for '${key}' must be non-empty strings`);
      }
      field = Type.Union(values.map(v => Type.Literal(v)));
    } else if (prop.type === 'string') {
      field = Type.String();
    } else if (prop.type === 'boolean') {
      field = Type.Boolean();
    } else {
      throw new Error(
        `native tool schema: unsupported type for '${key}' (only string / string-enum / boolean)`
      );
    }
    if (typeof prop.description === 'string') {
      field = Type.Unsafe<unknown>({ ...field, description: prop.description });
    }
    shape[key] = required.has(key) ? field : Type.Optional(field);
  }
  return Type.Object(shape);
}

/**
 * Adapt NativeTools to Pi `ToolDefinition`s for the `customTools` array. The
 * handler's text result becomes the tool's content; `details` is unused.
 */
export function buildPiNativeToolDefinitions(nativeTools: NativeTool[]): ToolDefinition[] {
  return nativeTools.map(spec =>
    defineTool({

View on GitHub (pinned to 0773b97458)

Solutions

Change numeric properties to `type: 'string'` and parse in the handler
Flatten nested object parameters into top-level string/boolean properties
Express a bounded list as a string enum where possible
If complex schemas are required, pass the tool through the regular (prompt-based) tool path instead of native tools

Example fix

// before
{ type: 'object', properties: { count: { type: 'integer' } } }
// after
{ type: 'object', properties: { count: { type: 'string', description: 'integer as string' } } }

Defensive patterns

Strategy: validation

Validate before calling

const SUPPORTED = new Set(['string', 'boolean']);
for (const [key, prop] of Object.entries(schema.properties)) {
  const ok = Array.isArray(prop.enum) || SUPPORTED.has(prop.type);
  if (!ok) throw new Error(`property '${key}' type '${prop.type}' unsupported; use string, string-enum, or boolean`);
}

Type guard

function isSupportedProperty(prop: unknown): boolean {
  if (typeof prop !== 'object' || prop === null) return false;
  const p = prop as { enum?: unknown; type?: unknown };
  return Array.isArray(p.enum) || p.type === 'string' || p.type === 'boolean';
}

Try / catch

try {
  const defs = buildPiNativeToolDefinitions(tools);
} catch (err) {
  if (err.message.includes('unsupported type')) {
    log.warn({ err: err.message }, 'native tool schema narrowed');
    // fall back to prompt-based tools for this tool
  } else throw err;
}

Prevention

Design native tool params using only string, string-enum, and boolean
Encode numbers as strings with a description, parse in the handler
Keep a unit test that converts every tool schema at registration time to catch regressions early

When it happens

Trigger: A property in inputSchema.properties with `type: 'number'`, `'integer'`, `'array'`, `'object'`, or no `type` and no `enum`, passed to buildPiNativeToolDefinitions.

Common situations: Schemas ported from richer tool frameworks that use numeric params or nested objects, and schemas where a property's `type` was forgotten entirely.

Related errors

AI-assisted analysis of coleam00/Archon@0773b97458 (2026-09-01). Data as JSON: /api/errors/772320eb68f5dca7. Report an issue: GitHub.