> ISPO SDK documentation. [HTML](https://ispo.ai/docs/interfaces/core.PromptToolResult.html) · [Documentation index](https://ispo.ai/docs/llms.txt)

# Interface PromptToolResult

The outcome of one tool invocation. The tool NAME generally lives on the call, not the result, so joining on [PromptToolResult.id](#id) is what identifies _which_ tool failed.

```typescript
interface PromptToolResult {
    id?: string;
    isError?: boolean;
    name?: string;
}
```

Types: [id](#id), [isError](#iserror), [name](#name)

##### Index

### <a id="properties"></a>Properties

[id?](#id) [isError?](#iserror) [name?](#name)

## <a id="properties-1"></a>Properties

### <a id="id"></a>`Optional`id

```typescript
id?: string
```

Provider call id of the invocation this answers.

### <a id="iserror"></a>`Optional`isError

```typescript
isError?: boolean
```

Provider-reported error flag.

**Absent means the store records no error signal at all — NOT success.** Claude marks `is_error` on every tool result; Codex records no equivalent, so Codex results always leave this undefined. Reading absence as a pass would count "not observable" as "worked", which is the failure mode that lets an eval report health it never measured.

### <a id="name"></a>`Optional`name

```typescript
name?: string
```

Tool name, only when the store records one on the result itself.