/**
 * Builds the MCP `ServerOptions` (capabilities + serverInfo) for a Scope.
 *
 * Extracted from `createInMemoryServer` so every transport that stands up an
 * `McpServer` for a Scope — in-memory, and the Web-fetch handler used by the
 * Cloudflare Worker target — advertises the SAME capability set. Capability
 * drift between transports is a real bug class (a client over HTTP sees an
 * extension the same Scope hides over the Worker), so this is the single
 * source of truth.
 */
import { type ServerCapabilities } from '@frontmcp/protocol';
import { type Scope } from '../scope/scope.instance';
/**
 * The MCP `ServerOptions.capabilities` type doesn't model the forward-compat
 * `extensions` key (reserved for SEP-2133), so we widen it locally rather than
 * casting through `Record<string, never>`. Runtime passthrough is unchanged.
 */
export type ServerCapabilitiesWithExtensions = ServerCapabilities & {
    extensions?: Record<string, unknown>;
};
export interface ScopedServerOptions {
    instructions: string;
    capabilities: ServerCapabilitiesWithExtensions;
    serverInfo: Scope['metadata']['info'];
}
/**
 * Compute the MCP server capabilities + serverInfo for a Scope.
 *
 * SEP-2640 / SEP-2133 capabilities live inside `experimental` / `extensions`,
 * so we lift those keys out of EVERY fragment (not just `scope.skills`) and
 * merge them — otherwise a client would miss extension capabilities that
 * another transport advertises against the same Scope.
 */
export declare function buildScopedServerOptions(scope: Scope, instructions?: string): ScopedServerOptions;
//# sourceMappingURL=build-scoped-server-options.d.ts.map