Research contexts
Named contexts group the sources belonging to a product, project or organisation. AI clients can discover safe source identities and capabilities without receiving private credential material.
Hexjack Lens · How it works
Lens gives authorised AI clients a stable way to discover and research configured organisational sources without exposing every provider API, credential or execution environment directly.
Named contexts group the sources belonging to a product, project or organisation. AI clients can discover safe source identities and capabilities without receiving private credential material.
Sources advertise search, retrieve and optional investigate capabilities, while trusted runtime policy determines the authority actually available.
The common source boundary is constructed around configured destinations. Caller requests do not contain arbitrary host, workspace, root or generic request selectors.
Contexts, not credentials
Lens separates non-secret topology from runtime credentials. A research context can describe which approved sources belong together and what each source supports while credentials are referenced by logical identity and resolved privately at the point of use.
Different sources can use independent credential profiles, and credential material can be rotated without rebuilding the application artifact or changing the public research topology.
Retrieve
Retrieval searches and reads existing information from authorised sources. It is intentionally bounded: the caller selects configured contexts and sources rather than arbitrary hosts, filesystems or network destinations.
The common adapter contract applies provider-neutral request and evidence bounds, normalised failure semantics and minimum provenance. Concrete source adapters then implement their own upstream behaviour within that boundary.
Atlassian
The Atlassian source provides explicit read-only MCP operations for configured sites: list approved site aliases, search Jira with JQL, read an issue, search Confluence with CQL and read a page.
Requests route through configured site aliases rather than caller-supplied hosts. Searches and page/issue reads are bounded, pagination state is preserved, upstream failures are normalised and returned content carries source identity and provenance as untrusted evidence.
The public surface deliberately contains no create, update, delete, transition or generic HTTP/request primitive.
Bitbucket
The Bitbucket source can list configured workspaces and repositories, read pull-request metadata and bounded diffs, and list and read commits through approved repository identities.
Collections and diffs are bounded, pagination and truncation are explicit, provider failures are normalised and repository content remains untrusted evidence. The adapter exposes no push, merge, commit, mutation or generic upstream request capability.
Hosted provider search is the fast direct-retrieval path and requires no local repository copy. Deployments that need deterministic file-at-ref reads or repeated literal code/text search can additionally enable Lens's private local Git-mirror retrieval capability.
Repository mirrors
repository.get_file and repository.search_code operate only on bare Git mirrors derived from configured source aliases. Callers cannot supply a repository URL, workspace, filesystem root or mirror path.
Each request resolves the requested branch, tag or commit to an immutable commit before reading. Results carry the configured source, requested ref, resolved commit and last-successful-refresh information, so a local snapshot is never silently described as current upstream state.
Local mirrors are optional retrieval infrastructure, not Lens's general synchronisation model and not a prerequisite for investigation. Mirror lifecycle stays internal and absent from the MCP tool surface. The mirror path is contained beneath the Lens cache root, unsafe filesystem indirections fail closed, credentials are runtime-only and Git is invoked without shell or repository-controlled execution.
Documents
Configured document-source aliases bind to operator-controlled roots. AI callers can search and retrieve through those aliases without supplying an arbitrary host, filesystem root or network path.
The reference local-filesystem adapter rejects traversal, hidden paths and symlinks, keeps reads and search results bounded, treats binary or oversized files as metadata-only evidence where appropriate and preserves source provenance as untrusted evidence. Provider-specific enterprise document systems remain separate adapters rather than being hidden behind generic filesystem access.
Investigate
Some questions require more than search: following code paths, testing hypotheses or examining an authorised environment. Lens uses a provider-neutral Analysis Engine Contract that carries bounded questions, configured context and source scope, correlation metadata and common evidence without exposing generic shell, SQL, container or provider-orchestration primitives.
That semantic contract is paired with authenticated destination-bound transport over verified HTTPS or a configured local Unix socket and is exposed through the public research.investigate MCP operation. Endpoints and credentials come from trusted configuration rather than caller input. The analysis provider can be a remote service such as an organisation's analysis platform or a local compatible agent, and it can own its own authorised checkout, runtime or tooling. Lens returns bounded evidence-backed findings without exposing that provider's execution authority to the MCP caller.
Operational controls
Lens records metadata-only operational audit events without request text, retrieved content, credentials, private endpoints or local paths. Runtime work is protected by finite concurrency and cancellation-aware limits, while deployment platforms retain independent CPU, memory, storage and log-retention controls.
Optional repository mirrors are treated as disposable source-data caches with explicit protection, backup and deletion guidance. Credentials can be rotated outside the application artifact, and diagnostic commands validate configuration, readiness, version and approved network destinations without exposing secret values.
Assembled-product verification
The Lens acceptance gate verifies standalone operation, the exact 21-tool read-only MCP contract, independent configured contexts, source isolation, provenance, delegated investigation, hostile-content handling, restricted-network startup, deployment hardening and release verification. Cross-context or unauthorised requests fail closed rather than widening scope.
Provider neutral
The product architecture separates the information-estate interface from provider implementations. Organisations can choose the systems and analysis environments appropriate to their own estate without changing the fundamental Lens contract.
The common evidence model applies across retrieval and delegated investigation. It distinguishes recorded source material, direct observations and inference, preserving provenance and support relationships without turning retrieved or generated content into trusted control instructions.
Evidence & provenance →