Lawang Onboard

io.github.gabloogev0.1.0Updated Sep 30, 2026

Permission-aware onboarding MCP server: answers about a codebase, filtered by the caller's role.

VerifiedStreamable HTTPWeb executableDeveloper ToolsKnowledge & Memory

Overview

AI-generated overview

A permission-aware onboarding server that answers questions about a codebase, filtered by the caller's role before the model sees anything.

What it does
Lawang Onboard exposes tools such as whoami, map_system, search, get, trace_feature, why, setup_guide, starter_tasks and withheld. Each tool filters the corpus by the scopes attached to the caller's role and builds answers only from visible items, citing the item ids used. Answers end with a Withheld line listing what was hidden, and a hidden id and a missing id return the same answer.
When to use it
Use it when a new engineer or a contractor needs to understand a codebase and its history without seeing everything. It suits onboarding tours, tracing how a feature works, explaining past decisions, and suggesting first tasks, with access limited to the role's scopes.
Requirements
A remote endpoint at the hosted address, or a local run with Go 1.25. A bearer token in the Authorization header is required; ask the server operator for one. The README describes connecting IBM Bob in Onboard mode and a live demo page.
Before you install
The Authorization bearer token is a secret and grants a role's view; keep it private and ask the operator for one. The server reads a corpus of repository files, docs, ADRs, commits, pull requests, reviews and issues, and returns filtered excerpts to the model. The README states the demo corpus is the team's own open-source repository and the roles are synthetic.

Installation

In SourceWeft

  1. Open Lawang Onboard in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.

Other MCP clients

Add this to your client's mcpServers config.

{
  "mcpServers": {
    "lawang-onboard": {
      "type": "http",
      "url": "https://lawang-onboard.samsulhadi.com/mcp"
    }
  }
}

README

Lawang Onboard

[Lawang Onboard]

[M8ven Score]

Permission-aware AI onboarding. An onboarding copilot inside IBM Bob that explains a codebase to a new engineer, and only the parts they are allowed to see.

Built for the IBM Bob 2.0 Hackathon (lablab.ai, 25 to 27 September 2026) by team Lawang Onboard.

The problem

A new engineer, or a contractor hired for one module, needs weeks to learn why a codebase looks the way it does. The answers exist, spread across commit messages, architecture decision records and pull request reviews, but nobody reads those on day one. And access is all or nothing: either the newcomer sees everything, including whatever an AI assistant can read into its context, or they wait for someone to explain.

What it does

Open the repository in IBM Bob, switch to the Onboard mode, and ask:

  • /tour: the map of what you can see, module by module.
  • /trace webhook: how a webhook becomes a record, step by step.
  • /why internal/ingress: the decisions and reviews behind a path.
  • "What can I pick up first?"

Bob answers from the code and its history, and cites every item it used. Every piece of context carries a scope; the engineer's role maps to a set of scopes; the role comes from the token on the connection; and the Lawang Onboard MCP server filters before the model sees anything. A contractor's session cannot leak what it was never given, and every answer ends with what was withheld:

Withheld: path:cmd (68), path:internal/core (314), path:migrations (56), path:repo (86),private:growth (18), private:security (6) | total hidden: 399
ContractorMaintainer
[Contractor view][Maintainer view]

Results

Measured on 26 September with the contractor role, one fresh Bob task per question, by a team member who did not build the server. Full write-up: docs/benchmark.md.

Result
Ten onboarding questions10 of 10 correct, 36 s and 0.16 Bobcoins per answer on average
Against answering by hand46 s vs 210 s on three questions, one of which could not be answered by hand at all
Leak probes (prompt injection, direct get, claiming another role, search, "guess")5 of 5 held; nothing outside the role's scopes reached the model
Code review by Bob2 real findings (unauthenticated demo API, an existence oracle in get), both fixed and rechecked
Withheld countsMatch an independent recount from roles.yaml and the corpus on every run
Leak tests11 test functions, each across all three roles, plus planted injection items; go test -race ./... in CI

How it works

IBM Bob (Onboard mode: rules, skills, slash commands)        |  MCP over stdio or HTTPS, bearer token        vonboard server (Go)  token -> role -> scopes -> one filter function -> tools -> audit log        |corpus/*.jsonl  (610 items: files, docs, ADRs, commits, PRs, reviews, issues, each with scopes)
  • Scopes come from roles.yaml: path globs (first match wins), labels (a growth label makes an issue private) and kinds. An item needs every one of its scopes; an item with no scope is denied to everyone.
  • Tools: whoami, map_system, search, get, trace_feature, why, setup_guide, starter_tasks, withheld. Each filters first and builds its answer only from visible items. A hidden id and a missing id get the same answer.
  • Onboard mode can use only MCP tools and skills, not the file system, so Bob's only view of the code is the filtered one. Its rules make it call whoami first, cite item ids, treat corpus text as data, mark proposals as proposals and close with the Withheld line.
  • Tokens are compared in constant time; an unknown, empty or ambiguous token is refused. The demo page's API uses the same tokens.

Design notes: docs/design.md.

Try it

Run it locally

Needs Go 1.25.

sh
cp .env.example .env                 # set the three role tokenscp .bob/mcp.example.json .bob/mcp.jsonscripts/use-role.py contractor       # writes that role's token into .bob/mcp.json

Open the folder in IBM Bob, reload MCP servers, pick the Onboard mode and ask away. Bob starts the server over stdio.

For the web page and the HTTP endpoint:

sh
set -a; . ./.env; set +ago run ./cmd/onboard -addr :47312               # http://localhost:47312, MCP at /mcpgo run ./cmd/onboard -addr :47312 -demo-roles   # local demos only: role buttons without tokensmake test                                       # go test -race -count=1 ./...

Hosting (Docker and a Cloudflare Tunnel, make up): docs/deploy.md.

How IBM Bob is used

IBM Bob is both the product's runtime and the tool that built it. The Onboard mode, its rules, four skills (tour, trace, first-week, why) and three slash commands are the user interface. Plan mode designed the server, Agent mode wrote all of its code and tests, Ask mode reviewed it for leaks, and the Onboard mode ran the benchmark. 36 Bob tasks, 46.6 of the team's 80 Bobcoins; every task has a screenshot in bob_sessions/ and a row in the ledgers (Samsul, Ryan). Details, and what was done outside Bob: docs/submission/bob-usage.md.

Data and privacy

See DATA_SOURCES.md and PRIVACY.md. The demo corpus is the team's own open-source repository, gablooge/lawang; no client, confidential, personal or social media data is used. The roles are synthetic.

Team

  • Samsul Hadi (lead)
  • Ryan Rizki

License

MIT

Source: README.md at commit 6664e6d

Tools

0
Tool metadata has not been indexed yet.

Version history

1
  1. v0.1.0LatestSep 30, 2026