> ## Documentation Index
> Fetch the complete documentation index at: https://docs.superwire.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Syntax Overview

> A practical map of Superwire blocks and what each one is for.

Superwire workflows are built from declaration blocks and references between those blocks.

```wire theme={"languages":{"custom":["/languages/wire.tmLanguage.json"]}}
input {
    topic: string
}

secrets {
    api_key: string
}

provider llm from openai {
    endpoint: "https://api.openai.com/v1"
    api_key: secrets.api_key
}

model fast from llm {
    id: "gpt-4.1-mini"
}

agent summarize {
    model: model.fast
    instruction: "Summarize {{ input.topic }}."

    output {
        summary: string
    }
}
```

## Declaration blocks

Use these blocks to define what a workflow needs, how it runs, and what it returns.

| Block                                                      | What it defines                                          | Why it exists                                                                 |
| ---------------------------------------------------------- | -------------------------------------------------------- | ----------------------------------------------------------------------------- |
| `input { ... }`                                            | Public request data for the workflow.                    | Makes runtime inputs explicit and typed.                                      |
| `secrets { ... }`                                          | Sensitive request data such as API keys.                 | Keeps credentials separate from normal input.                                 |
| `schema name { ... }`                                      | Reusable structured types.                               | Avoids repeating the same object shapes across blocks.                        |
| `provider name from openai { ... }`                        | A configured backend endpoint and auth settings.         | Centralizes provider connection details for models.                           |
| `model name from provider { ... }`                         | A named model profile (`id`, inference defaults).        | Lets multiple agents share model settings.                                    |
| `mcp name { ... }`                                         | An MCP server connection.                                | Declares external capability endpoints once.                                  |
| `tool local_name from mcp.server.tool.remote_name`         | A tool imported from an MCP server.                      | Exposes deterministic actions to agents.                                      |
| `resource local_name from mcp.server.resource.remote_name` | A resource imported from an MCP server.                  | Exposes read-only external content.                                           |
| `prompt local_name from mcp.server.prompt.remote_name`     | A prompt template imported from MCP.                     | Reuses centrally managed prompt assets.                                       |
| `dynamic { ... }`                                          | Computed values derived from references and expressions. | Prepares runtime values before agent execution.                               |
| `agent name { ... }`                                       | One model-backed execution step.                         | Encapsulates instruction, file attachments, tools, context, and typed output. |
| `output { ... }`                                           | Final response payload of the workflow.                  | Defines exactly what `/execute` returns.                                      |

## Typical flow

Most workflows follow this shape:

```text theme={"languages":{"custom":["/languages/wire.tmLanguage.json"]}}
input + secrets -> provider -> model -> agent(s) -> output
```

When MCP is used, tools/resources/prompts become additional inputs available to agents.

## Common expressions

```wire theme={"languages":{"custom":["/languages/wire.tmLanguage.json"]}}
"text"
123
true
input.topic
secrets.api_key
agent.summarize.summary
schema.shared.status
call tool.fetch_context { bindings { task_id: input.task_id } }
read resource.project_readme
render prompt.instructions
context: agent.investigate_task
```

References are how data moves through the workflow. For example, `agent.summarize.summary` uses a previous agent result, while `secrets.api_key` injects a credential into provider config.

## Naming

Prefer lowercase `snake_case` for schemas, agents, tools, resources, prompts, providers, models, and fields.