LocalCloud MCP server
Commit 5. Nov. 2026Bietet eine lokale Cloud-Umgebung für AI Agents, um Google Cloud Anwendungen über eine Model Context Protocol Bridge zu bauen, zu testen und zu debuggen.
Auch bekannt als LocalGCloud/localcloud-cli, localcloud-cli
- Stars
- 1
- Tools
- —
- Downloads, 30 Tage
- —
- Neueste Version
- 0.1.12
- Letzter Commit
- 5. Nov. 2026
- Lizenz
- —
Was ist LocalCloud MCP?
LocalCloud ist ein MCP server. Bietet eine lokale Cloud-Umgebung für AI Agents, um Google Cloud Anwendungen über eine Model Context Protocol Bridge zu bauen, zu testen und zu debuggen.
Zusammenfassung generiert aus dem README des Projekts
Über LocalCloud MCP server
LocalCloud bietet eine lokale Cloud-Umgebung, die speziell für Entwickler und AI Coding Agents entwickelt wurde, um Google Cloud Anwendungen zu bauen, zu testen und zu debuggen, ohne Service-Gebühren zu verursachen. Durch die Nutzung einer Model Context Protocol Bridge ermöglicht das System AI Agents, direkt mit lokalen Services zu interagieren, was es ihnen erlaubt, innerhalb ihres eigenen Workflows Ressourcen bereitzustellen, Daten zu seeden, zu inspizieren und den State zurückzusetzen. Die Umgebung läuft in einem Docker Container und verwaltet den Lifecycle verschiedener Services über ein einzelnes CLI Tool.
Nutzer interagieren mit dem System über die localcloud oder lc Command-Line Interface. Um bestehenden Anwendungscode anzubinden, führen Entwickler einen Befehl aus, der Umgebungsvariablen exportiert, welche die offiziellen Google Client Libraries auf lokale Loopback-Endpoints umleiten. Dieses Setup erfordert Docker und mindestens 4 GiB verfügbaren Arbeitsspeicher. Die Plattform unterstützt 27 verschiedene Services, darunter BigQuery, Pub/Sub, Spanner, Cloud SQL und Cloud Storage, wodurch sichergestellt wird, dass der Anwendungscode unverändert bleibt, während er gegen eine lokale, persistente Infrastruktur läuft.
Was du damit machen kannst
- 1Automatisierte Bereitstellung der UmgebungEin AI Agent kann als Teil seines Coding Loops eine lokale Google Cloud Umgebung aufsetzen und verwalten.
- 2Kostenloses Testen von AnwendungenEntwickler können komplexe Service-Workflows lokal ausführen, um Google Cloud Service-Gebühren zu vermeiden.
- 3Nahtlose SDK-IntegrationDu kannst Standard Google Client Libraries in deinem Code verwenden, ohne Endpoint-Argumente modifizieren zu müssen.
Geschrieben aus dem README des Projekts. Jeder Use Case wurde gegen ein Zitat daraus geprüft.
Konfiguration
BIGQUERY_EMULATOR_HOSTBIGTABLE_EMULATOR_HOSTCLOUDSDK_API_ENDPOINT_OVERRIDES_STORAGECLOUDSDK_CORE_PROJECTGOOGLE_BIGQUERY_CUSTOM_ENDPOINTGOOGLE_CLOUD_PROJECTGOOGLE_OAUTH_ACCESS_TOKENGOOGLE_PROJECTGOOGLE_STORAGE_CUSTOM_ENDPOINTLOCALCLOUD_RUN_IDENTITY_E2ENO_COLORSPANNER_EMULATOR_HOSTSTORAGE_EMULATOR_HOST
| Name | Beschreibung | Typ |
|---|---|---|
| BIGQUERY_EMULATOR_HOST | — | |
| BIGTABLE_EMULATOR_HOST | — | |
| CLOUDSDK_API_ENDPOINT_OVERRIDES_STORAGE | — | |
| CLOUDSDK_CORE_PROJECT | — | |
| GOOGLE_BIGQUERY_CUSTOM_ENDPOINT | — | |
| GOOGLE_CLOUD_PROJECT | — | |
| GOOGLE_OAUTH_ACCESS_TOKEN | — | |
| GOOGLE_PROJECT | — | |
| GOOGLE_STORAGE_CUSTOM_ENDPOINT | — | |
| LOCALCLOUD_RUN_IDENTITY_E2E | — | |
| NO_COLOR | — | |
| SPANNER_EMULATOR_HOST | — | |
| STORAGE_EMULATOR_HOST | — |
Automatisierte Checks
Geluften am 14. Nov. 2026Vollständiger Bericht →Noch nicht verifiziert. Ein Server benötigt einen Score von 80, keine kritischen Befunde und genug Daten für unsere Prüfung. Wie die Checks funktionieren
- Source Repository verknüpft und erreichbarlocalgcloud/localcloud-cli is public and reachablegithub.com/localgcloud/localcloud-cli ↗Bestanden
- Paket nennt dieses Repository als QuelleNicht geprüft
- Build-Herkunft (Sigstore-Attestierung)Nicht geprüft
- Open Source Lizenz (OSI)No licenseBefund
- Commit oder Release im letzten JahrLast commit or release 2026-11-05github.com/localgcloud/localcloud-cli ↗Bestanden
- OpenSSF ScorecardNicht geprüft
- Package-Name ähnelt keinem populären PackageNicht geprüft
- Kein kritischer Hinweis im Paket oder seinen AbhängigkeitenNicht geprüft
- Keine versteckten Anweisungen an das Modell0 tool descriptions and the README read; no override phrases, credential paths or hidden charactersBestanden
- Destruktive Tools sind markiertNicht geprüft
- Remote-Endpoint beantwortet den MCP-HandshakeNicht geprüft
README
Auf GitHub ansehenLocalCloud CLI
A free local cloud environment for developers and AI coding agents.
Build, test, and debug Google Cloud applications from your terminal or coding agent. MCP connects your agent to local services, SDK configuration, test data, readiness, and diagnostics.
Run local service workflows without Google Cloud service charges, start with one command, and create local projects for your experiments and test suites within your machine's capacity.
Website · MCP guide · Claude & Codex marketplace setup
Install · Quickstart · How it works · Services · Commands · AI agents & MCP · Troubleshooting
localcloud (aliased lc) is the official host CLI for LocalCloud. It manages the
container runtime lifecycle, multi-project context, SDK environment variables, persistent Docker volumes,
and the Model Context Protocol bridge — so your application code keeps calling the same Google Cloud client
libraries it already uses, just pointed at loopback.
$ lc doctor
╭── LocalCloud v0.1.14 ───────────────────────────────────────────────────────────────────────╮
│ │ Top commands │
│ Checking LocalCloud setup │ localcloud (or lc) status | start | stop | restart │
│ │ eval $(lc env) Exports env vars that redirect cloud se…│
│ ╭────╮ │────────────────────────────────────────────────────────────────│
│ ╭──╯ ╰──╮ │ Context │
│ ╭─╯ ╰─╮ │ Data Volume: localcloud-data Project: local-gcp-project│
│ ╭╯ ╰╮ │ User: local-developer │
│ ╰──────────────╯ │ Config: built-in defaults (overridable by ./localcloud.yaml) │
│ │ │
├────────────────────────────┴────────────────────────────────────────────────────────────────┤
│ Supported Services (● 22 enabled · ○ 5 disabled) │
│ ● Storage ● Pub/Sub ○ Firestore ● Bigtable ● Spanner ● BigQuery │
│ ● Cloud SQL ● AlloyDB ● Memorystore ● Dataproc ● Tasks ● Scheduler │
│ ● Functions ○ Cloud Run ○ Compute ○ GKE ● Workflows ○ Vertex AI │
│ ● Sheets ● KMS ● Secrets ● IAM ● Logging ● Monitoring │
│ ● Resource Mgr ● Service Usage ● Billing │
╰─────────────────────────────────────────────────────────────────────────────────────────────╯
Tip: Run localcloud guide for AI agent workflows, or lc for the fast alias.
Docker 29.8.1 (/opt/homebrew/bin/docker) · Colima 0.10.1 (VZ, Rosetta on)
Image agentcloud/localcloud:lite (ID: 66d2113a69fb)
Ports 5380-5406 (in use by localcloud)
[OK] LocalCloud is ready to start 0.5s
Why LocalCloud
- 27 services, one container. Storage, Pub/Sub, BigQuery, Spanner, Bigtable, Firestore, IAM, KMS, Dataproc, Cloud Run and more come up together — not as a dozen emulators you wire up by hand.
- Your SDK code doesn't change.
eval "$(lc env)"exports the emulator variables the official Google client libraries already look for. Same calls, same objects, loopback endpoints. - Isolated, durable environments. A named Docker volume is the runtime's identity. Run a scratch environment for CI beside your everyday one, and keep data across restarts.
- Built for humans and automation. Every command renders a readable terminal summary, and the same
result as complete JSON with
--verbose.--dry-runpreviews mutations;--debugprints the equivalentdocker run. - Agent-native. A first-class MCP bridge lets AI coding agents provision, seed, inspect, and reset real GCP-shaped state as part of their own loop — not a UI a person has to click through.
- Zero live-cloud footprint. The CLI validates that every generated endpoint is loopback and refuses to
emit a real
googleapis.comaddress. There is no silent fallback to production.
How it compares
| LocalCloud | gcloud beta emulators |
Testcontainers | Real GCP dev project | |
|---|---|---|---|---|
| Services | 27 | ~5 (Bigtable, Datastore/Firestore, Pub/Sub, Spanner) | Wraps the same emulators | All |
| Setup | One CLI command | One process per service | Written in test code | Project, billing, IAM |
| SDK wiring | eval "$(lc env)" |
Per-emulator, manual | Per-container, in code | ADC + real credentials |
| Web console | Built in | — | — | Yes |
| Terraform / OpenTofu | lc env --format terraform |
— | — | Yes |
| Agent control (MCP) | Built in | — | — | — |
| Data persistence | Docker volume, survives restarts | Process lifetime | Test lifetime | Durable |
| Cost / credentials | None | None | None | Billed, real keys |
Breadth is service availability — a callable, service-level integration. Operation-level parity is service-specific and recorded per service in the LocalCloud compatibility matrix.
Install
Prerequisites
Docker Desktop, Colima, OrbStack, Rancher Desktop, or Docker Engine, installed and running. LocalCloud needs at least 4 GiB of memory available to the container for stable operation.
No Docker yet? On macOS with Homebrew, lc doctor --fix (or lc start in a terminal) offers to install
Colima, a free, lightweight Docker engine, and starts it with 4 CPUs
and 8 GiB of memory.
On Apple Silicon, run the Docker VM on VZ with Rosetta rather than QEMU: it is faster, and QEMU has
known issues with LocalCloud (the BigQuery emulator can fail under it). lc doctor reports the Docker
app, its VM type and Rosetta, and lc doctor --fix offers to switch Colima or Rancher Desktop.
macOS and Linux
curl -fsSL https://local.cloud/install.sh | sh
The installer adds localcloud and the shorter lc alias when available.
Homebrew
brew install LocalGCloud/tap/localcloud
brew upgrade localcloud # upgrade
brew uninstall localcloud # remove
Upgrading
Update the CLI to the latest release:
lc update
lc update detects how LocalCloud was installed (script installer or Homebrew) and upgrades the CLI in place. For Homebrew, brew upgrade localcloud also works.
Standalone binaries
Signed release archives with Sigstore verification bundles are published for:
| Platform | Architectures | Minimum |
|---|---|---|
| macOS | Apple Silicon | macOS 13+ |
| Linux | x86_64, aarch64 |
glibc 2.35+ (Ubuntu 22.04+) |
Intel Macs are not supported: 0.1.11 was the last release with an Intel macOS archive.
Windows users can run the container directly — see the Docker setup instructions.
Verify
$ lc --version
localcloud 0.1.14 (commit c2bed60e4464, released 2026-11-03)
Release builds embed their exact source commit and release date, so a binary can always be traced back.
Quickstart
Five minutes from nothing to a working Cloud Storage bucket.
1. Check your machine
lc doctor
Confirms Docker connectivity, reports the Docker app and its VM setup, and shows the resolved LocalCloud
context. Continue when the last line starts with [OK]. It creates no LocalCloud state, so it is always safe
to run first.
If it lists Setup findings, lc doctor --fix offers to fix them, asking before each change.
2. Start the runtime
lc start
Config built-in defaults (overridable by ./localcloud.yaml)
Data volume localcloud-data
Origin managed
Project local-gcp-project
User local-developer
Image agentcloud/localcloud:lite
Image status Available locally
URL http://127.0.0.1:5380
Ports 5380-5406
Services alloydb, bigquery, bigtable, cloudbilling, cloudfunctions, cloudiam,
cloudresourcemanager, cloudscheduler, cloudsql, cloudtasks, dataproc, gcs,
kms, logging, memorystore, monitoring, pubsub, secretmanager, serviceusage,
sheets, spanner, workflows
[OK] LocalCloud is ready 8.4s
start checks the registry for a newer image by default (--no-pull to skip), publishes the canonical
ports on all host interfaces, waits for service readiness, and tails logs for five seconds.
A service that reports a permanent failure doesn't fail the start. The command succeeds and warns
that the service is not available, giving the runtime's reason.
Use lc start --local-only to bind published ports to 127.0.0.1 instead.
Pass --local-only on subsequent start, restart, and reset commands to keep that binding.
Running start again on a live runtime is safe.
3. Configure your shell
eval "$(lc env)"
This exports the variables the official Google client libraries already read:
export STORAGE_EMULATOR_HOST="http://127.0.0.1:5382"
export BIGQUERY_EMULATOR_HOST="http://127.0.0.1:5388"
export SPANNER_EMULATOR_HOST="127.0.0.1:5386"
export BIGTABLE_EMULATOR_HOST="127.0.0.1:5385"
export GOOGLE_CLOUD_PROJECT="local-gcp-project"
export CLOUDSDK_CORE_PROJECT="local-gcp-project"
export CLOUDSDK_API_ENDPOINT_OVERRIDES_STORAGE="http://127.0.0.1:5382/"
# …one entry per enabled service, plus gcloud endpoint overrides and a local access token
4. Call it from your code
No LocalCloud-specific client. No endpoint arguments. The environment does the work.
Python
from google.cloud import storage
client = storage.Client()
bucket = client.create_bucket("my-bucket")
bucket.blob("hello.txt").upload_from_string(
"Hello from LocalCloud!"
)
Node.js / TypeScript
import { Storage } from "@google-cloud/storage";
const storage = new Storage();
const [bucket] = await storage.createBucket("my-bucket");
await bucket.file("hello.txt")
.save("Hello from LocalCloud!");
Go
ctx := context.Background()
client, _ := storage.NewClient(ctx)
defer client.Close()
bucket := client.Bucket("my-bucket")
_ = bucket.Create(ctx, "local-gcp-project", nil)
gcloud CLI
gcloud storage buckets create gs://my-bucket
gcloud storage ls
5. Look around, then stop
lc console # open the web console for the selected project
lc status # runtime health, endpoints, and ownership
lc logs # recent runtime logs
lc restart # recreate runtime with current local image (--pull to check registry)
lc stop # stop the container; the data volume is untouched
Your data survives stop and restart. lc start brings it back exactly as it was.
Tip for AI coding agents: Skip manual shell setup! Head to AI agents & MCP to configure Cursor, Claude Code, or Windsurf in one command (
lc mcp install).
How it works
your code ──► google-cloud-* SDK ──► 127.0.0.1:5380-5406 ─────────┐
terraform ──► GOOGLE_*_CUSTOM_ENDPOINT ───────────────────────────┤
AI agent ──► lc mcp (stdio) / :5380/mcp (HTTP) ──────────────────┤
│
┌─────────────────────────────────────────────┘
┌───────────▼─────────────────────────────────────────────┐
│ Docker container · agentcloud/localcloud │
│ │
│ :5380 gateway · console · admin API · MCP · facades │
│ :5382 Cloud Storage :5386-87 Spanner │
│ :5383 Pub/Sub :5388-89 BigQuery │
│ :5384 Firestore :5390 Memorystore │
│ :5385 Bigtable :5391 PostgreSQL │
└───────────────────┬─────────────────────────────────────┘
│
Docker volume: localcloud-data
mounted at : /var/lib/localcloud
The CLI never becomes a proxy — it configures and supervises. Once lc start returns, your SDK talks to
the container directly.
Three identities, deliberately separate
This is the one concept worth internalizing, because every flag follows from it:
| Axis | Flag | What it selects | Scope |
|---|---|---|---|
| Data volume | --data-volume |
The durable runtime identity — a named Docker volume mounted at /var/lib/localcloud. Two volumes are two independent LocalClouds. |
Docker |
| Project | --project-id |
A logical Google Cloud project inside one runtime. Many projects share a volume. start and MCP startup create a missing one. |
Request |
| User | --user |
The attributed caller sent to LocalCloud services, normalized to <name>@localcloud.invalid where a principal is required. |
Request |
Project and user are request context: switching them is instant and never touches Docker. Defaults are
localcloud-data, local-gcp-project, and local-developer. The MCP bridge instead gives each git
repository its own project, named after the repository, unless --project-id or the repository's
localcloud.yaml names one.
Ports
New runtimes prefer the canonical range 5380–5405 (plus DNS 5410/udp). With Cloud SQL MySQL
enabled, the set also includes 5406, which LocalCloud's MySQL companion container publishes. If that
complete set is unavailable, the CLI proposes one contiguous alternative from 5508–5539, then
5821–5840, then 5322–5342, and asks before creating the container. Such a runtime publishes only
the ports its enabled services use, so four can run beside the canonical one. To pick the host ports
yourself, set host.port_range: 6000-6099 or pass --port-range 6000-6099. The CLI never scans the
operating system's general ephemeral range, and lc env always emits the ports actually in use.
Services
27 Google Cloud–compatible services, 22 enabled by default:
| Group | Services |
|---|---|
| Storage & databases | Cloud Storage, Firestore, Bigtable, Spanner, BigQuery, AlloyDB, Cloud SQL, Memorystore |
| Messaging & orchestration | Pub/Sub, Cloud Tasks, Cloud Scheduler, Cloud Workflows |
| Compute & serverless | Cloud Functions, Cloud Run, Compute Engine, GKE, Dataproc |
| Security & identity | Cloud IAM, Secret Manager, Cloud KMS |
| Management & billing | Resource Manager, Service Usage, Cloud Billing |
| Observability | Cloud Logging, Cloud Monitoring |
| AI & productivity | Vertex AI, Google Sheets |
Use the ID with --services or services.enabled in localcloud.yaml.
| ID | Google Cloud service | Default |
|---|---|---|
gcs |
Cloud Storage | ● on |
pubsub |
Pub/Sub | ● on |
firestore |
Firestore | ○ off |
bigtable |
Bigtable | ● on |
spanner |
Spanner | ● on |
bigquery |
BigQuery | ● on |
sheets |
Google Sheets | ● on |
secretmanager |
Secret Manager | ● on |
cloudtasks |
Cloud Tasks | ● on |
cloudscheduler |
Cloud Scheduler | ● on |
cloudfunctions |
Cloud Functions (2nd Gen) | ● on |
alloydb |
AlloyDB | ● on |
dataproc |
Dataproc | ● on |
cloudiam |
Cloud IAM | ● on |
cloudresourcemanager |
Cloud Resource Manager | ● on |
serviceusage |
Service Usage | ● on |
cloudbilling |
Cloud Billing | ● on |
logging |
Cloud Logging | ● on |
monitoring |
Cloud Monitoring | ● on |
gke |
GKE | ○ off |
compute |
Compute Engine | ○ off |
cloudrun |
Cloud Run | ○ off |
memorystore |
Memorystore (Redis/Valkey) | ● on |
workflows |
Cloud Workflows | ● on |
vertexai |
Vertex AI | ○ off |
kms |
Cloud KMS | ● on |
cloudsql |
Cloud SQL | ● on |
● on services start automatically
when services.enabled is unset; ○ off services are available but must be selected explicitly.
Select an explicit set at start time, or reset to the built-in default:
lc start --services gcs,pubsub,bigquery,firestore
lc start --services default
Services you enable or disable in the Console are saved on the data volume and come back on the next
start. --services outranks them for that start without clearing them, and start prints a
Service sources line naming where each enabled service came from. See
Which services run.
Lite and full images. lc start runs the lite image (agentcloud/localcloud:lite) by default. It has
every service above, but BigQuery's lite edition (no BigQuery ML, JavaScript UDFs, or EXTERNAL_QUERY on
Cloud SQL; Spanner's still works), and GKE creates metadata-only clusters. --full runs the full image
(:latest, or <version> instead of <version>-lite); the runtime keeps it on later starts and restarts
until --lite.
lc start --full
Staying current. A runtime keeps the image it was started with. A floating tag like lite is
refreshed by --pull. A version tag like agentcloud/localcloud:0.1.8-lite never moves by itself,
so start and restart look for a newer version on the same channel (lite or full) and, in a terminal,
ask before switching:
A newer LocalCloud image is available for this runtime.
Current agentcloud/localcloud:0.1.8-lite (the image data volume 'localcloud-data' last ran)
Offered agentcloud/localcloud:0.1.11-lite (Docker Hub; will be pulled, 373.1 MB)
The runtime is recreated on the new image and its data volume is migrated forward, so going back may not be possible.
Use 0.1.11-lite now? [y/N]
The check reads Docker Hub's tag list at most once every 6 hours. When Docker Hub can't be reached,
it offers newer images already on your machine instead. A "no" is remembered for that data volume
until a newer version appears. Scripts and --verbose runs never switch: they get an Image update
line instead. An explicit --pull switches without asking. Set LOCALCLOUD_IMAGE_UPDATE_CHECK=false
to turn the check off. See Which image runs.
Commands
lc and localcloud are interchangeable in every example.
| Command | Purpose |
|---|---|
lc update |
Update the CLI through its script installer or Homebrew |
lc doctor |
Inspect Docker access, VM engine, and host setup; --fix interactively resolves issues |
lc start |
Start the runtime; supports --services, --local-only, --tls, --no-ui, and creating the project named by --project-id |
lc status |
Show runtime health, ownership, endpoints, and Docker details |
lc env |
Generate SDK, Terraform, or Docker Compose configuration; --identity starts a local identity session |
lc console |
Open the web console for the selected project and user |
lc logs |
Print recent runtime logs |
lc restart |
Recreate the container with the local image (default: --no-pull); --pull checks the registry and moves a pinned version to the newest |
lc reset |
Reset the selected project (--all-projects prints manual recreate steps) |
lc stop |
Stop the runtime without deleting persistent data |
lc cleanup |
Remove malformed Docker resources, stale runtime state, and legacy files |
lc guide |
Print authoritative coding-agent guidance |
lc mcp |
Run the stdio MCP bridge; lc mcp install configures AI coding agents |
Run lc COMMAND --help for command-specific flags and the valid --fields paths.
Output modes
Every command speaks to a person and to a script from the same result:
| Flag | Effect |
|---|---|
| (none) | Concise terminal summary, with spinners and elapsed time in an interactive shell |
--verbose |
The complete structured result as JSON on stdout |
--fields PATH[,PATH…] |
Append specific JSON paths to the concise summary |
--dry-run |
Validate and print every planned Docker and LocalCloud mutation, changing nothing |
--debug |
Diagnostics on stderr, including a copyable equivalent docker run command |
lc status --verbose | jq '.container.url'
lc start --fields mcp.direct_url,container.name
lc start --dry-run # preview before mutating anything
NO_COLOR=1 lc doctor # symbols still carry status without color
Service selection is marked with ● (on) and ○ (off) as well as color, so it stays legible under
NO_COLOR or a dumb terminal.
Exit codes
| Code | Meaning |
|---|---|
0 |
Success |
1 |
Completed with failures (for example cleanup partial), or an unexpected internal error |
2 |
LocalCloud error — invalid input, Docker problem, or a failed operation. Rendered as Error [code] message |
130 |
Command interrupted with Ctrl-C |
LocalCloud MCP Fragen
Wie arbeitet LocalCloud mit bestehenden Google Cloud SDKs zusammen?
Es nutzt Umgebungsvariablen, um die offiziellen Google Client Libraries auf lokale Loopback-Endpoints umzuleiten, sodass dein Code keine Änderungen benötigt.
Fallen für LocalCloud Gebühren für Google Cloud Services an?
Nein, es ist eine kostenlose lokale Umgebung, die darauf ausgelegt ist, Workflows auszuführen, ohne Google Cloud Service-Gebühren zu verursachen.
Welche Hardware-Anforderungen gibt es für LocalCloud?
LocalCloud benötigt eine Docker-kompatible Runtime und mindestens 4 GiB verfügbaren Arbeitsspeicher für den Container.
Kann ich meine Daten behalten, nachdem ich die Runtime gestoppt habe?
Ja, die Daten werden in einem benannten Docker Volume gespeichert, das über Stopps und Neustarts hinweg erhalten bleibt.