> ## Documentation Index > Fetch the complete documentation index at: https://docs.leapter.com/llms.txt > Use this file to discover all available pages before exploring further. # Inputs and Outputs > How parameters work in Leapter — every Blueprint has its own signature, and the project's external interface is made of the signatures of its public Blueprints. Every Blueprint in Leapter has its own **signature** — the inputs it expects and the outputs it returns. A project usually contains several Blueprints: one or more public entry points, and sub-Blueprints called via [Call nodes](/elements/calling-other-blueprints). The signatures of the **public** Blueprints form the project's externally visible interface. This page covers both perspectives: what a Blueprint signature is, and how public Blueprints determine the project's API. ## Per-Blueprint signature Each Blueprint has: * **Inputs** — the values it receives when it runs * **Outputs** — the values it returns when it finishes * **Local variables** — internal scratch space, not visible to callers You see and edit a Blueprint's signature in the [Contents sidebar](/editor/toolbars-and-panels#contents-sidebar): click the **Show inputs and outputs** icon (⇆) next to the Blueprint name. The Blueprint expands to show its inputs and outputs in line. In the [Specification view](/editor/specification-view#edit-inputs-outputs-and-locals), each Blueprint chapter lists its inputs, outputs, and locals, where you can add and edit them. The Contents sidebar with the Loan Application Scorecard Blueprint expanded — the green spark marks the Execution Scope, and the Inputs and Outputs are listed below with fields to set values and the results of the last run Each parameter has: * **Label** — the name used to reference this value in your logic (e.g., `monthlyIncome`, `existingDebt`) * **Type** — what kind of data it holds: a basic type such as `text`, `number`, `boolean`, `date`, `date-time`, or `percent`, or one of your project's [Type Definitions](/editor/type-definitions) * **Description** — explains what the value represents * **Default** — the value used when a caller leaves the input out * **Required** — for inputs only: whether the caller must provide the value * **Allow multiple values** — whether the parameter holds a list of values instead of a single value * **Rules** — depending on the type: **Allowed values** for a fixed list, **Value bounds** (Min / Max) for a number, or **Length bounds** for a text Leapter checks every input against its type and rules before the logic runs. A missing required input, a value of the wrong type, or a value outside its rules is rejected — in the editor, the input is marked as missing or invalid; through the API, the call fails with a validation error. ### Outputs are never required Only inputs can be required. An output that a run does not set is simply left out of the result, and the editor shows it as **not set**. Give an output a **Default** if callers should always receive a value. ### List parameters When you check **Allow multiple values**, the parameter accepts a list of values. This is useful when your Blueprint needs to process multiple items — like a list of order amounts or customer names. Use [Loop elements](/elements/controlling-the-flow#loops) to iterate over list inputs. ### Local variables Local variables are internal to the Blueprint that defines them. Use them for intermediate calculations, counters, or temporary values. They aren't visible to other Blueprints and aren't part of any signature. You don't have to declare a local before you use it. When you assign a value to a name the Blueprint doesn't know yet, Leapter asks what the name should hold — **What does** *name* **hold?** — and offers **Create variable**. If the name looks like a typo of an existing one, it asks **Did you mean** *name*? instead. Expression tooltips and autocomplete label every name as **Input**, **Output**, or **Local**. ## Public Blueprints and the project's external interface When someone calls your project through the [REST API](/release-and-integrate/connect-rest-api) or [MCP](/release-and-integrate/connect-mcp), they call one of its **public** Blueprints in the latest [release](/release-and-integrate/releases). Each public Blueprint's signature **is** an external interface: * The inputs a caller sends are this Blueprint's inputs * The outputs a caller receives are this Blueprint's outputs A project can have several public Blueprints, so it can offer several entry points with different signatures. Private Blueprints have signatures too, but only other Blueprints in the project can call them. The Contents sidebar lists your Blueprints under **Public** and **Private** — see [Public and private Blueprints](/release-and-integrate/releases#public-and-private-blueprints) to change which group a Blueprint belongs to. ### The Execution Scope in the editor The Blueprint marked with a green spark icon (⚡) in the Contents sidebar is the **Execution Scope**. It decides which Blueprint runs when you work in [Live mode](/test-and-validate/test-your-blueprint#live-mode) in the editor. To change it, click the spark icon next to another Blueprint (**Set as execution scope**). The Execution Scope only affects runs in the editor. It doesn't change what callers can reach — that is decided by which Blueprints are public. ## Why per-Blueprint signatures matter | Context | What a signature does | | :- | :- | | **Testing in the editor** | Quick-run controls show input fields based on the Blueprint's inputs and display its outputs. While [Live mode](/test-and-validate/test-your-blueprint#live-mode) is running, every change re-runs and refreshes the outputs. | | **Call nodes** | When one Blueprint calls another, it maps values into the called Blueprint's inputs and captures its outputs — see [Calling Other Blueprints](/elements/calling-other-blueprints) | | **REST API** | Callers send a public Blueprint's inputs as JSON and receive its outputs in the response | | **MCP** | AI assistants use each public Blueprint's signature to understand what it does and how to call it | | **Specification view** | Every Blueprint's chapter lists its inputs, outputs, and locals, and the Contents sidebar shows them for a quick run | ## Tips * Use descriptive names — `cartValue` is better than `val1` * Write descriptions as if explaining to someone who's never seen the project — they show up in the API surface and in any [public share](/workspace/sharing) * Only mark inputs as required if the Blueprint truly cannot function without them * Reach for [Type Definitions](/editor/type-definitions) when several inputs or outputs share the same shape — define the type once and reuse it across Blueprints ## What to do next * **[Type Definitions](/editor/type-definitions)** — define reusable Value Types and Data Types * **[Calling Other Blueprints](/elements/calling-other-blueprints)** — pass typed values between Blueprints * **[Test your Blueprint](/test-and-validate/test-your-blueprint)** — set values and run from the Contents sidebar This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.