Docs menu
Get started
Quickstart Install: Claude Code Install: Codex Install: other clients API keysConcepts
How a run works The app profile The severity model What a run does not sayTools
check_access claim_trial_key set_profile run_lint get_law resolve_domain_jurisdiction submit_feedback upload_lint_runGuides
A whole run, end to end Console TestPack in CIReference
Endpoint and transport lexlint.yml schema Errors ChangelogHelp
Support and feedbackTools
set_profile
Declare what the app does and where it operates. Nothing is stored.
What it does
Step 1 of the lint. Declare what the app does and where it operates; get back the validated,
canonical profile plus what the LexLint law library holds for each jurisdiction, so you know the depth
of a run before spending it. Write the returned profile into the project's
lexlint.yml and pass it to run_lint. It takes the same declaration as
run_lint, and the table below lists each parameter.
It stores nothing. mcp.lexlint.io has no session, and splitting the lint in two did not give it one: the profile lives in your repository, not here. An unknown activity or a malformed slug is refused at this step rather than quietly weakening a lint later, and a malformed slug is refused outright, by name, before any request is spent. A profile that lints clean over fewer places than you declared is worse than an error, so this step will not hand you one.
It costs one upstream request for any number of jurisdictions. That is a separate
request from check_access's own, but it answers the same coverage question, so
asking both gets you that answer twice for the two calls a normal run already makes, not for
a third one. If you are calling check_access a second time later, for example to
revalidate a local cache, ask it or set_profile for coverage, never
both, since a second check_access call really is a second request.
Parameters
| Name | Type | Required | What it takes |
|---|---|---|---|
activities | string[] | yes | What the app does. Allowed: crawls_web, trains_models, generates_content, deploys_chatbot, automated_outreach, high_risk_decisions, processes_voice, processes_biometrics, publishes_adult_content, operates_social_platform, serves_minors, operates_app_store, ships_mobile_app, aggregates_content, distributes_software_product, handles_health_records, provides_financial_services, operates_essential_service, is_listed_company, provides_telecom_services, statutory_requests, records_conversations, tracks_devices |
jurisdictions | string[] | yes | Jurisdiction slugs, lowercase, "/"-separated (e.g. "us", "us/ca", "eu", "kr"). A slug is the jurisdiction's UnGovr Atlas path: California is https://ungovr.org/us/ca and its Atlas ID is urn:ungovr:us/ca. Its ISO 3166 code, US-CA, is accepted too. A deeper or unresearched path resolves to the nearest jurisdiction with law, and the jurisdictions whose law is researched are listed at https://lexlint.io/law for the developer to check; name every jurisdiction the app operates in: one left off is unlinted, not passed. |
public_sector | string[] | no | Is this software run by a public body (body), sold to or run for public bodies (supplier), both, or neither (none)? Ask the developer every time the profile is declared; never infer it from the code. Omitted, duties binding only public bodies are reported as the caller's, and run_lint counts them in a coverage line. |