export interface MCPTool {
    name: string;
    description: string;
    inputSchema: any;
    outputSchema?: any;
    tags?: string[];
}
export interface MCPFetchResult {
    requiresAuth: boolean;
    tools: MCPTool[];
    authMetadataUrl?: string;
}
/** Fetch MCP tool definitions from a remote MCP server. */
export declare function fetchMCPTools(serverUrl: string): Promise<MCPFetchResult>;
/** Read MCP tool definitions from a wrapped or raw JSON array. */
export declare function readMCPToolsFromFile(filePath: string): Promise<MCPTool[]>;
/**
 * What a probe learned about the URL itself, independently of whether authorization is needed.
 *
 * - `confirmed`: something MCP-shaped answered — either a successful `initialize` or an OAuth
 *   challenge. The URL is right.
 * - `notEndpoint`: the server answered definitively and the answer was not MCP. The URL is
 *   most likely wrong.
 * - `undetermined`: nothing was learned (server error, timeout, DNS or transport failure).
 *   Says nothing about the URL and must never be reported as a problem with it.
 */
export type MCPEndpointStatus = "confirmed" | "notEndpoint" | "undetermined";
export interface MCPAuthProbeResult {
    requiresAuth: boolean;
    authMetadataUrl?: string;
    /**
     * Whether the URL was confirmed to be an MCP endpoint. Reported separately from `requiresAuth`
     * because it says whether the URL is right, not whether authorization is missing. A mistyped
     * URL commonly still serves an ordinary page on GET — the host's landing page, say — which
     * makes it look reachable; only the `initialize` POST exposes that nothing MCP is there.
     */
    endpointStatus: MCPEndpointStatus;
    /** The HTTP status behind a `notEndpoint` verdict. Absent for the other two states. */
    responseStatus?: number;
}
/** Probe an MCP streamable-HTTP endpoint for an OAuth challenge and for the URL's validity. */
export declare function probeMCPServerAuth(serverUrl: string): Promise<MCPAuthProbeResult>;
export interface MCPOAuthMetadata {
    authorizationUrl: string;
    tokenUrl: string;
    refreshUrl?: string;
    wellKnownUrl: string;
}
/**
 * Build the ordered list of authorization-server metadata URLs to probe for an issuer.
 *
 * Providers disagree on which discovery form they serve: RFC 8414 §3.1 mandates inserting
 * `/.well-known/oauth-authorization-server` between the host and the issuer path, while
 * OpenID Connect Discovery §4 appends `/.well-known/openid-configuration` to the issuer.
 * Microsoft Entra, for example, serves ONLY the appended OIDC form — the RFC 8414 insertion
 * form returns 404 — so probing a single form silently loses the endpoints for whole classes
 * of identity providers. Candidates are deduplicated (a host-only issuer collapses the
 * insertion and append forms) and returned in RFC-preference order.
 */
export declare function buildWellKnownCandidates(issuer: string): string[];
/**
 * Build the ordered list of authorization-server metadata URLs to probe for an MCP server that
 * never pointed at an authorization server.
 *
 * MCP servers written against the 2025-03-26 authorization spec are their own authorization
 * server: they publish RFC 8414 metadata at the origin root and ship no RFC 9728
 * protected-resource document at all. Such a server answers the 401 challenge with `realm`
 * alone, so `resource_metadata` discovery dead-ends and the endpoints have to be derived from
 * the server URL instead. Path-derived forms are probed first, because a host exposing several
 * MCP endpoints may serve per-endpoint metadata; the origin root is the last resort.
 */
export declare function buildMCPServerWellKnownCandidates(mcpServerUrl: string): string[];
/**
 * Build the RFC 9728 protected-resource metadata URLs to probe for an MCP server that never
 * advertised one.
 *
 * A server only hands out its `resource_metadata` location inside a `WWW-Authenticate`
 * challenge, and a server that defers authorization to the individual tool calls answers an
 * unauthenticated `initialize` with a plain 200 and no challenge at all — Google's Gmail,
 * Calendar and Drive servers do exactly that, yet each publishes a protected-resource document
 * naming `https://accounts.google.com/`. Waiting to be told therefore loses the metadata for a
 * whole class of servers, so the document is derived from the resource URL instead, as MCP's
 * authorization spec requires of clients. RFC 9728 §3.1 inserts the well-known segment between
 * the host and the resource path; the path-less form follows for servers that publish at the
 * origin root only.
 */
export declare function buildProtectedResourceCandidates(mcpServerUrl: string): string[];
/** Resolve OAuth endpoints from MCP resource or authorization-server metadata. */
export declare function resolveMCPOAuthMetadata(authMetadataUrl?: string, wellKnownUrl?: string, mcpServerUrl?: string): Promise<MCPOAuthMetadata>;
//# sourceMappingURL=mcpToolFetcher.d.ts.map