@lunora/mcp 1.0.0-alpha.14 → 1.0.0-alpha.141

package/LICENSE.md

@@ -103,3 +103,129 @@ Unless required by applicable law or agreed to in writing, software distributed
 under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR
 CONDITIONS OF ANY KIND, either express or implied. See the License for the
 specific language governing permissions and limitations under the License.
+
+<!-- DEPENDENCIES -->
+<!-- /DEPENDENCIES -->
+
+<!-- TYPE_DEPENDENCIES -->
+
+# Licenses of bundled types
+The published @lunora/mcp artifact additionally contains code with the following licenses:
+FSL-1.1-Apache-2.0
+
+# Bundled types:
+## @lunora/x402
+License: FSL-1.1-Apache-2.0
+By: Daniel Bannert
+Repository: git+https://github.com/anolilab/lunora.git
+
+> # Functional Source License, Version 1.1, Apache 2.0 Future License
+>
+> ## Abbreviation
+>
+> FSL-1.1-Apache-2.0
+>
+> ## Notice
+>
+> Copyright 2026 anolilab and contributors
+>
+> ## Terms and Conditions
+>
+> ### Licensor ("We")
+>
+> The party offering the Software under these Terms and Conditions.
+>
+> ### The Software
+>
+> The "Software" is each version of the software that we make available under
+> these Terms and Conditions, as indicated by our inclusion of these Terms and
+> Conditions with the Software.
+>
+> ### License Grant
+>
+> Subject to your compliance with this License Grant and the Patents,
+> Redistribution and Trademark clauses below, we hereby grant you the right to
+> use, copy, modify, create derivative works, publicly perform, publicly display
+> and redistribute the Software for any Permitted Purpose identified below.
+>
+> ### Permitted Purpose
+>
+> A Permitted Purpose is any purpose other than a Competing Use. A Competing Use
+> means making the Software available to others in a commercial product or service
+> that:
+>
+> 1. substitutes for the Software;
+>
+> 2. substitutes for any other product or service we offer using the Software that
+>    exists as of the date we make the Software available; or
+>
+> 3. offers the same or substantially similar functionality as the Software.
+>
+> Permitted Purposes specifically include using the Software:
+>
+> 1. for your internal use and access;
+>
+> 2. for non-commercial education;
+>
+> 3. for non-commercial research; and
+>
+> 4. in connection with professional services that you provide to a licensee using
+>    the Software in accordance with these Terms and Conditions.
+>
+> ### Patents
+>
+> To the extent your use for a Permitted Purpose would necessarily infringe our
+> patents, the license grant above includes a license under our patents. If you
+> make a claim against any party that the Software infringes or contributes to the
+> infringement of any patent, then your patent license to the Software ends
+> immediately.
+>
+> ### Redistribution
+>
+> The Terms and Conditions apply to all copies, modifications and derivatives of
+> the Software.
+>
+> If you redistribute any copies, modifications or derivatives of the Software,
+> you must include a copy of or a link to these Terms and Conditions and not
+> remove any copyright notices provided in or with the Software.
+>
+> ### Disclaimer
+>
+> THE SOFTWARE IS PROVIDED "AS IS" AND WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR
+> IMPLIED, INCLUDING WITHOUT LIMITATION WARRANTIES OF FITNESS FOR A PARTICULAR
+> PURPOSE, MERCHANTABILITY, TITLE OR NON-INFRINGEMENT.
+>
+> IN NO EVENT WILL WE HAVE ANY LIABILITY TO YOU ARISING OUT OF OR RELATED TO THE
+> SOFTWARE, INCLUDING INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES, EVEN
+> IF WE HAVE BEEN INFORMED OF THEIR POSSIBILITY IN ADVANCE.
+>
+> ### Trademarks
+>
+> Except for displaying the License Details and identifying us as the origin of
+> the Software, you have no right under these Terms and Conditions to use our
+> trademarks, trade names, service marks or product names.
+>
+> ## Grant of Future License
+>
+> We hereby irrevocably grant you an additional license to use the Software under
+> the Apache License, Version 2.0 that is effective on the second anniversary of
+> the date we make the Software available. On or after that date, you may use the
+> Software under the Apache License, Version 2.0, in which case the following will
+> apply:
+>
+> Licensed under the Apache License, Version 2.0 (the "License"); you may not use
+> this file except in compliance with the License.
+>
+> You may obtain a copy of the License at
+>
+> http://www.apache.org/licenses/LICENSE-2.0
+>
+> Unless required by applicable law or agreed to in writing, software distributed
+> under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR
+> CONDITIONS OF ANY KIND, either express or implied. See the License for the
+> specific language governing permissions and limitations under the License.
+>
+> <!-- DEPENDENCIES -->
+> <!-- /DEPENDENCIES -->
+
+<!-- /TYPE_DEPENDENCIES -->

package/README.md

@@ -34,20 +34,32 @@
 
 ---
 
-A [Model Context Protocol](https://modelcontextprotocol.io) server that exposes a deployed Lunora app to AI agents. It registers tools for introspecting a deployment (`lunora_list_functions`, `lunora_list_tables`, `lunora_get_function_schema`) and invoking its functions (`lunora_run_query`, `lunora_run_mutation`, `lunora_run_action`), each backed by `@lunora/client` over HTTP RPC.
+[Model Context Protocol](https://modelcontextprotocol.io) servers for Lunora, in two flavours:
+
+- **Deployment** (the main entry) — exposes a deployed Lunora app to AI agents: introspection tools (`lunora_list_functions`, `lunora_list_tables`, `lunora_get_function_schema`) and invocation tools (`lunora_run_query`, `lunora_run_mutation`, `lunora_run_action`), each backed by `@lunora/client` over HTTP RPC. Needs an admin token.
+- **Documentation** ([`@lunora/mcp/docs`](#documentation-server)) — exposes the framework's _docs_ so an agent writing Lunora code can look up the real API instead of guessing. Credential-free, and safe to host publicly; Lunora runs it at `https://lunora.sh/mcp`.
+
+Most users never install this package directly — `lunora mcp install` wires both servers into their editor. See [`@lunora/cli`](https://www.npmjs.com/package/@lunora/cli).
 
 Part of the [Lunora](https://github.com/anolilab/lunora) framework — a type-safe, real-time backend on Cloudflare Workers + Durable Objects with a Vite-first DX.
 
 ## Tools
 
-| Tool                         | Description                                                                                                    |
-| ---------------------------- | -------------------------------------------------------------------------------------------------------------- |
-| `lunora_list_functions`      | List the deployment's public functions (queries, mutations, actions) with their kinds.                         |
-| `lunora_list_tables`         | List the deployment's `.global()` tables with their row counts.                                                |
-| `lunora_get_function_schema` | Return a function's argument descriptors and kind by path, so a caller can construct a valid arguments object. |
-| `lunora_run_query`           | Run a query and return its result. Read-only.                                                                  |
-| `lunora_run_mutation`        | Run a mutation and return its result. Writes data — use with care.                                             |
-| `lunora_run_action`          | Run an action and return its result. May call external services.                                               |
+| Tool                          | Description                                                                                                                                                   |
+| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `lunora_list_functions`       | List the deployment's public functions (queries, mutations, actions) with their kinds.                                                                        |
+| `lunora_list_tables`          | List the deployment's `.global()` tables with their row counts.                                                                                               |
+| `lunora_get_function_schema`  | Return a function's argument descriptors and kind by path, so a caller can construct a valid arguments object.                                                |
+| `lunora_run_query`            | Run a query and return its result. Read-only.                                                                                                                 |
+| `lunora_run_mutation`         | Run a mutation. Writes data. Two-step: propose, then confirm with the returned `actionDigest`.                                                                |
+| `lunora_run_action`           | Run an action. May call external services. Two-step: propose, then confirm with the returned `actionDigest`.                                                  |
+| `lunora_get_logs`             | Read the deployment's recent log entries (newest first). Requires an admin token.                                                                             |
+| `lunora_get_issues`           | List errors grouped into Issues by fingerprint, with counts and triage status. Requires an admin token.                                                       |
+| `lunora_get_advisories`       | List the deployment's schema/query advisories. Requires an admin token.                                                                                       |
+| `lunora_get_query_insights`   | Per-statement execution counts and latency over a recent window. Requires an admin token.                                                                     |
+| `lunora_get_migration_status` | Which migrations are applied and which are pending. Requires an admin token.                                                                                  |
+| `agent_<name>`                | Start a durable [`@lunora/agent`](https://www.npmjs.com/package/@lunora/agent) run and await its answer. One tool per exposed agent. Requires agents enabled. |
+| `lunora_agent_status`         | Poll a running agent by `threadKey` and return its answer once finished. Requires agents enabled.                                                             |
 
 ### Recommended agent flow
 
@@ -56,8 +68,101 @@ Part of the [Lunora](https://github.com/anolilab/lunora) framework — a type-sa
 2. lunora_get_function_schema     → retrieve the argument descriptors for a specific path
 3. lunora_run_query / lunora_run_mutation / lunora_run_action
                                   → call the function with a well-formed arguments object
+                                    (the two write tools take a second, confirming call)
 ```
 
+### Write confirmation (the two-step handshake)
+
+`LUNORA_MCP_ALLOW_WRITES` decides whether this server may write at **all**. It
+never said anything about whether a _particular_ write was reviewed, so past that
+gate `lunora_run_mutation` and `lunora_run_action` each take two calls.
+
+The first call **executes nothing**. It returns the proposed action and a digest:
+
+```jsonc
+{
+    "status": "action_required",
+    "actionDigest": "1789129912052.0ZR2…",
+    "expiresAt": "2026-09-11T14:41:52.052Z",
+    "proposedAction": {
+        "tool": "lunora_run_mutation",
+        "kind": "mutation",
+        "functionPath": "messages:send",
+        "args": { "roomId": "r1", "text": "hi" },
+    },
+    "nextStep": "Show proposedAction to a human. To execute, call …",
+}
+```
+
+Render `proposedAction` for a human, then call the same tool again — before
+`expiresAt` — with the identical `functionPath` / `args` / `shardKey` /
+`idempotencyKey`, plus `confirmed: true` and that `actionDigest`. Only then does
+the write happen.
+
+The digest is `<expiresAt>.<signature>`, where the signature is an HMAC over a
+canonical (sorted-key) encoding of the tool name, function path, arguments, shard
+key, idempotency key **and that deadline**, keyed by the deployment's own
+identity. So:
+
+- **Argument key order is irrelevant** — re-serializing `args` does not invalidate a confirmation.
+- **Any real edit invalidates it.** A different target, argument, or shard key produces a different digest, and the confirmation is refused with nothing written. That is the guarantee: what executes is exactly what was reviewed.
+- **It expires after 10 minutes.** The deadline travels in the clear (the verifying instance has to read it) but is signed alongside the proposal, so moving it breaks the signature. An expired digest is refused, not silently re-proposed — call again without `confirmed` for a fresh one.
+- **No server state is involved.** The HTTP handler serves statelessly (a fresh server per request), so a confirmation is revalidated by recomputation on whichever instance receives it, not looked up in a store.
+
+`idempotencyKey` is optional and is folded into the digest. A client that timed
+out can resubmit the confirmation it already holds, for as long as that digest is
+inside its window, without asking for a second review; and a deliberately-repeated
+identical write under a **new** key gets its own review instead of riding the
+first one. It does **not** deduplicate the write: this server keeps no state
+between requests and never forwards the key to your function, so a resubmitted
+confirmed call executes again. Make the function itself idempotent if the write
+must happen at most once.
+
+#### What the handshake does not do
+
+It binds **intent, not human presence**, and the difference matters when you
+decide whether to enable writes at all.
+
+A verified digest proves the call about to run is exactly the call that was
+proposed, on this deployment, inside its window. It does **not** prove a human
+saw it, and no server-side check can: an MCP server has no channel to a person —
+no session, no end-user identity, no UI — and MCP deliberately puts the
+human-in-the-loop at the **host**. The client is what renders a tool call for
+approval. A client that asks nobody can take the digest it was just handed, send
+it straight back with `confirmed: true`, and the write runs.
+
+That is why writes are off by default and refused at dispatch as well as omitted
+from `ListTools`: enabling `LUNORA_MCP_ALLOW_WRITES` is **your** statement that
+the client on the other end does the asking. Treat the handshake as a client-UI
+affordance and an audit record of what was proposed, not as a gate against the
+model.
+
+Two more scope limits, stated rather than implied:
+
+- **The digest is deployment-wide, not principal-bound.** Its key is the domain separator, the deployment URL and the admin bearer — nothing identifying a user. On an OAuth-fronted server (`createAuthedMcpFetchHandler`) every principal shares that bearer, so within the 10-minute window any principal holding write scope can confirm another's identical proposal. Binding it to a person would mean folding the verified `sub` claim into the signing key, which this package does not do today.
+- **It survives an admin-bearer rotation only as long as the bearer does.** Rotating `LUNORA_ADMIN_TOKEN`, or moving the deployment URL, invalidates every outstanding digest — which is the intended behaviour, not a bug to work around.
+
+### Observability tools (privileged)
+
+The five `lunora_get_*` observability tools are read-only, but they surface the
+deployment's **operational data** — log lines, request metadata, and grouped
+error messages, all of which may contain user data, and all of which land in the
+model's context (and therefore at its provider). They are therefore **off by
+default**: set `LUNORA_MCP_ALLOW_OBSERVABILITY=1` (or pass
+`allowObservability: true`) to expose them. Without it they are omitted from
+`ListTools` entirely and refused at dispatch, the same omit-don't-refuse rule the
+write tools use. They are independent of `--allow-writes`, which is about
+changing data, not reading operational data — and independent of the admin
+bearer, which every tool already needs, so holding it is not the opt-in.
+
+They return `structuredContent` alongside the usual text block, described by each
+tool's `outputSchema` (MCP revision `2025-06-18` and later; older clients keep
+reading the text block). All but `lunora_get_migration_status` take a `limit`
+clamped server-side; migration status takes only `shardKey` and returns every
+migration, because truncating that list would hide the pending one. Each also
+takes an optional `shardKey` — on a `.shardBy()`-partitioned deployment these
+reads are **per-shard**, not deployment-wide.
+
 `lunora_get_function_schema` returns a JSON object with three fields:
 
 - `path` — the function path (e.g. `"messages:send"`)
@@ -70,6 +175,8 @@ Part of the [Lunora](https://github.com/anolilab/lunora) framework — a type-sa
 npm install @lunora/mcp
 ```
 
+Paid MCP tools (`createPaidMcpServer`) additionally need the optional peer [`@lunora/x402`](https://www.npmjs.com/package/@lunora/x402); it is loaded lazily, so installs that never charge for a tool don't pay for its dependency tree.
+
 ```sh
 yarn add @lunora/mcp
 ```
@@ -80,7 +187,7 @@ pnpm add @lunora/mcp
 
 ## Usage
 
-MCP clients spawn the `lunora-mcp` binary over stdio. Configuration comes from `LUNORA_URL` (required) and `LUNORA_ADMIN_TOKEN` (optional bearer token):
+MCP clients spawn the `lunora-mcp` binary over stdio. Configuration comes from `LUNORA_URL` and `LUNORA_ADMIN_TOKEN` — both required (see [Tokens](#tokens)):
 
 ```jsonc
 {
@@ -105,6 +212,117 @@ const server = createLunoraMcpServer({ url: "https://app.example.workers.dev", t
 await server.connect(myTransport);
 ```
 
+## Expose an agent
+
+A deployment's durable [`@lunora/agent`](https://www.npmjs.com/package/@lunora/agent) agents can be fronted as MCP tools. This is **opt-in and fail-closed**, mirroring `allowWrites`: starting an agent run is a side effect, so the agent tools are omitted from the advertised list _and_ refused at dispatch unless you explicitly enable them. `@lunora/mcp` takes no dependency on `@lunora/agent` — it reaches the agent's public `agents:agentRun` mutation over RPC like any other function.
+
+Two opt-ins are needed, on **both** sides:
+
+1. **On the agent**, `defineAgent({ publicRun: true })`. `agents:agentRun` refuses
+   any agent without it (`FORBIDDEN`), because starting a durable run from
+   outside the deployment is a side effect the agent's author has to allow. The
+   env vars below do not grant it — an agent exposed here but not marked
+   `publicRun` is advertised and fails on its first call.
+2. **On this server**, the env vars (or the matching `createLunoraMcpServer` options):
+
+- `LUNORA_MCP_ALLOW_AGENTS` — set to `1`/`true`/`yes`/`on` to expose the agent tools. Default: agents disabled.
+- `LUNORA_MCP_AGENTS` — a `;`-separated list of `name:description` pairs selecting which agents to expose, e.g. `"support:Support questions;billing:Billing help"`.
+- `LUNORA_MCP_AGENT_TIMEOUT_MS` (optional) — wall-clock budget a single `agent_<name>` call awaits before returning a pending result to poll.
+
+```jsonc
+{
+    "mcpServers": {
+        "lunora": {
+            "command": "lunora-mcp",
+            "env": {
+                "LUNORA_URL": "https://app.example.workers.dev",
+                "LUNORA_ADMIN_TOKEN": "...",
+                "LUNORA_MCP_ALLOW_AGENTS": "1",
+                "LUNORA_MCP_AGENTS": "support:Support questions;billing:Billing help",
+            },
+        },
+    },
+}
+```
+
+Each exposed agent gets an `agent_<name>` tool taking `prompt` (required), an optional `threadKey` (reuse to continue a conversation; omit to start a new thread), and an optional `title`. The tool starts a durable run and awaits it up to the timeout budget; if the run outlasts the budget it returns a pending result whose `threadKey` you feed to the generic `lunora_agent_status` tool to poll for the final answer.
+
+Runs are **owner-scoped** to the identity the configured token resolves to — which is the deployment's **admin** identity, because `LUNORA_ADMIN_TOKEN` is what every tool needs (see [Tokens](#tokens)). Every agent thread this server starts therefore belongs to that one identity; run a separate MCP server per deployment if you need them kept apart.
+
+### Tokens
+
+`LUNORA_ADMIN_TOKEN` must be the deployment's **admin bearer**. It cannot be scoped down: `lunora_list_functions`, `lunora_list_tables`, and the allowlist precheck that runs before _every_ `lunora_run_*` call all hit admin-gated `/_lunora/admin/*` routes, so a least-privilege token returns `ADMIN_FORBIDDEN` on the first tool call. Constructing a server without one fails fast rather than advertising tools that cannot work.
+
+The read-only guarantee therefore does **not** come from the token's scope — it comes from `LUNORA_MCP_ALLOW_WRITES` defaulting off, which omits the write tools from `tools/list` _and_ refuses them at dispatch. Treat the MCP server itself as the trust boundary: give it the admin token, and gate who can reach it (the OAuth-protected `createAuthedMcpFetchHandler` is the supported way to expose it beyond a local stdio process).
+
+## Resources and annotations
+
+Both servers implement MCP **tools**; the documentation server additionally exposes every page as an MCP **resource** (`lunora-docs:/docs/…`, `text/markdown`), so a client can enumerate and attach a page directly instead of the model having to guess a search query first.
+
+Every tool carries **annotations** — `readOnlyHint`, `destructiveHint`, `idempotentHint`, `openWorldHint` and a human-facing `title` — so a client can badge the read-only surface and confirm before a write. They are hints; the actual guarantee is still made at dispatch, where a write tool is refused unless writes are enabled.
+
+## Documentation server
+
+`@lunora/mcp/docs` is a second, independent surface: it serves **published documentation**, not a deployment. No credentials, no writes, no `@lunora/client` — and no Node built-ins, so it runs unchanged on Workers, Netlify/Vercel functions, Deno, and Bun.
+
+| Tool                 | Description                                                           |
+| -------------------- | --------------------------------------------------------------------- |
+| `lunora_search_docs` | Search the docs; returns matching pages and sections with their URLs. |
+| `lunora_get_doc`     | Return one page in full, as Markdown.                                 |
+| `lunora_list_docs`   | List every page with its title and description.                       |
+
+The tools read a `DocsIndex`, which has two implementations. A docs site wires up its own in-process index and mounts the server as an HTTP route:
+
+```ts
+import { createDocsMcpFetchHandler } from "@lunora/mcp/docs";
+
+const handle = createDocsMcpFetchHandler({ index: myDocsIndex });
+
+// e.g. in a Worker: export default { fetch: handle }
+```
+
+Anything else reads a published site over HTTP:
+
+```ts
+import { createDocsMcpServer, createRemoteDocsIndex } from "@lunora/mcp/docs";
+
+const server = createDocsMcpServer({ index: createRemoteDocsIndex({ baseUrl: "https://lunora.sh" }) });
+```
+
+Point a client at the hosted endpoint with no install at all:
+
+```sh
+claude mcp add --transport http lunora-docs https://lunora.sh/mcp
+```
+
+### Hosting it safely
+
+`createDocsMcpFetchHandler` screens each request before the transport sees it, because this surface is meant to be public and unauthenticated:
+
+- **Bodies are capped** (128 KiB by default; override with `maxRequestBytes`).
+- **JSON-RPC batches are refused.** The stateless transport buffers a whole batch's replies into one response, so a single small request carrying thousands of `tools/call` messages would amplify into hundreds of megabytes out, with no session to rate-limit against. A docs client gains nothing from batching.
+- `lunora_search_docs` bounds its `query`, and `lunora_list_docs` caps how many pages it serialises.
+
+## Local development server
+
+`createLocalMcpServer` / `connectLocalStdio` compose the docs tools, the deployment tools, and any extra tools a host supplies into one stdio server — this is what `lunora mcp serve` runs.
+
+```ts
+import { connectLocalStdio } from "@lunora/mcp";
+
+await connectLocalStdio({
+    // Consulted per tool call, so a dev server started later is picked up
+    // without reconnecting.
+    deployment: () => readMyDevServer(),
+    docs: { baseUrl: "https://lunora.sh" },
+    extraTools: myLocalTools,
+});
+```
+
+The deployment tools are advertised even when the resolver currently returns nothing — MCP clients cache the tool list, so a surface that appeared only when the dev server happened to be up would stay invisible for the rest of the session. Calling one with nothing running returns an actionable error instead.
+
+The observability tools are the exception: their gate is snapshotted when the tool list is built, so a session started before `lunora dev` never advertises them (and the cached list keeps them absent afterwards). Restart the MCP server once the dev server is up.
+
 > This README covers the basics. For the full API, options, and guides, see the **[documentation](https://lunora.sh/docs)**.
 
 ## Related
@@ -112,6 +330,7 @@ await server.connect(myTransport);
 - [`@lunora/client`](https://www.npmjs.com/package/@lunora/client) — the HTTP RPC client backing every tool.
 - [`@lunora/cli`](https://www.npmjs.com/package/@lunora/cli) — deploy the app the server introspects and invokes.
 - [`@lunora/server`](https://www.npmjs.com/package/@lunora/server) — defines the queries, mutations, and actions the tools call.
+- [`@lunora/agent`](https://www.npmjs.com/package/@lunora/agent) — the durable agents the `agent_<name>` tools front over RPC.
 
 ## Supported Node.js Versions
 

package/dist/bin.mjs

@@ -1,38 +1,5 @@
 #!/usr/bin/env node
-import { connectStdio } from './packem_shared/connectStdio-nl-Tt_T1.mjs';
-
-const ENABLED_ENV_VALUES = /* @__PURE__ */ new Set(["1", "on", "true", "yes"]);
-const isEnvEnabled = (value) => value !== void 0 && ENABLED_ENV_VALUES.has(value.trim().toLowerCase());
-class BinError extends Error {
-  code;
-  constructor(message, code) {
-    super(message);
-    this.name = "BinError";
-    this.code = code;
-  }
-}
-const runBin = async (environment, dependencies = {}) => {
-  const connect = dependencies.connect ?? connectStdio;
-  const writeError = dependencies.writeError ?? ((message) => {
-    process.stderr.write(message);
-  });
-  const url = environment.LUNORA_URL;
-  if (url === void 0 || url.length === 0) {
-    writeError("lunora-mcp: LUNORA_URL environment variable is required\n");
-    throw new BinError("LUNORA_URL environment variable is required", 1);
-  }
-  try {
-    await connect({ allowWrites: isEnvEnabled(environment.LUNORA_MCP_ALLOW_WRITES), token: environment.LUNORA_ADMIN_TOKEN, url });
-  } catch (error) {
-    const message = error instanceof Error ? error.message : String(error);
-    writeError(`lunora-mcp: failed to start — ${message}
-`);
-    throw new BinError(`failed to start — ${message}`, 1);
-  }
-};
-
-try {
-  await runBin(process.env);
-} catch (error) {
-  process.exit(error instanceof BinError ? error.code : 1);
-}
+import{parseAgentsEnv as N}from"./packem_shared/AGENT_RUN_INPUT_SCHEMA-hKbpa3Dg.mjs";import{connectStdio as l}from"./packem_shared/connectStdio-CQI9JGJC.mjs";const E=new Set(["1","on","true","yes"]),o=r=>r!==void 0&&E.has(r.trim().toLowerCase());class s extends Error{code;constructor(e,a){super(e),this.name="BinError",this.code=a}}const O=async(r,e={})=>{const a=e.connect??l,i=e.writeError??(t=>{process.stderr.write(t)}),n=r.LUNORA_URL;if(n===void 0||n.length===0)throw i(`lunora-mcp: LUNORA_URL environment variable is required
+`),new s("LUNORA_URL environment variable is required",1);const c=r.LUNORA_ADMIN_TOKEN;if(c===void 0||c.length===0)throw i(`lunora-mcp: LUNORA_ADMIN_TOKEN environment variable is required (every tool reads admin-gated routes)
+`),new s("LUNORA_ADMIN_TOKEN environment variable is required",1);const A=Number(r.LUNORA_MCP_AGENT_TIMEOUT_MS),_=Number.isFinite(A)&&A>0?A:void 0;try{await a({agents:N(r.LUNORA_MCP_AGENTS),allowAgents:o(r.LUNORA_MCP_ALLOW_AGENTS),allowDataReads:o(r.LUNORA_MCP_ALLOW_DATA_READS),allowObservability:o(r.LUNORA_MCP_ALLOW_OBSERVABILITY),allowWrites:o(r.LUNORA_MCP_ALLOW_WRITES),token:c,url:n,..._===void 0?{}:{agentMaxWaitMs:_}})}catch(t){const L=t instanceof Error?t.message:String(t);throw i(`lunora-mcp: failed to start — ${L}
+`),new s(`failed to start — ${L}`,1)}};try{await O(process.env)}catch(r){process.exit(r instanceof s?r.code:1)}