Skip to main content
Glama

LexLint: compliance lint for AI, scraping, and privacy law

Upload this run to the LexLint portal

upload_lint_run
Idempotent

Store one lint run on the LexLint portal, against the UnGovr account that signed in or owns the key, and return the portal URL and, for a trial key, a share URL that opens the run with no sign-in for 30 days. This is the closing step of every run that produced findings, raised unprompted in exactly one place, the close of that run, and never volunteered anywhere else. Before the call the developer is shown the payload, exactly what will leave the repository, and the approval they give to the call is the yes; a declined approval means nothing was sent. Where the client asks nothing before a call, the agent asks the developer once itself. Never run it in a headless or CI session where nobody can approve anything. TWO FORMS. Prefer the compact one: app_name, the activities and jurisdictions run_lint ran on, and that reply's corpus_built_at AND run_at; the server rebuilds the findings itself, judged at that same run_at and refused if the law library moved or the approval went stale, so what is stored is what the developer saw. Add work_items and vanished when they have triaged. The full payload form is for a client already holding a complete ungovr.lexlint-upload/1 record. Either way the stored run is the app name and profile, findings, work items and envelope, never the API key, source files, prompts, transcripts or git identity. Uploads are immutable; a changed run stores a new revision. This tool needs sign-in or an UnGovr Open Data key.

Input Schema

NameRequiredDescriptionDefault
rolesNoCompact form. The declaration run_lint ran on.
run_atNoCompact form. run_at from that same reply. The rebuild is judged at this instant, because a finding's kind and severity move with the clock as well as with the law library.
payloadNoFull form. The complete ungovr.lexlint-upload/1 object: schema, generated_at, client_version, record. payload_hash is optional: the server derives it from record, and one you send must match it exactly.
app_nameNoCompact form. The repository's own name.
app_repoNoCompact form, optional. The repository URL.
vanishedNoCompact form, optional. Findings an earlier run carried and this one does not.
app_scopeNoCompact form, optional. What this run read when it was not the whole repository: one directory as a string, relative to the repository root, or the manifest's scope object, {include: [...], exclude: [...]}, when it read several. A one-off scope is never written to the manifest, and an upload without it is captioned as the whole repository.
activitiesNoCompact form. The declaration run_lint ran on.
work_itemsNoCompact form, optional. The developer's own triage.
jurisdictionsNoCompact form. The declaration run_lint ran on.
public_sectorNoCompact form. The declaration run_lint ran on.
client_versionNoCompact form, optional. The bundle version that ran the lint, stored with the run. A bundle whose server entry sends it as the X-LexLint-Bundle header on every call need not repeat it here.
findings_stateNoCompact form, optional. The developer's per-finding triage, keyed by finding id, each value holding any of state, where, note and handled_by. Applied to the rebuilt findings by id; an id this run does not carry is refused, because that triage is another run's.
corpus_built_atNoCompact form. corpus_built_at from the run_lint reply the developer approved.
regulated_sectorNoCompact form. The declaration run_lint ran on.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover only safety hints, and the description supplies everything an agent actually needs: auth requirement (sign-in or UnGovr Open Data key), immutability plus new-revision-on-change semantics, server-side rebuild and refusal conditions (law library moved, stale approval, triage id not in this run), and an explicit exclusion list of what is never stored. That is far beyond what readOnlyHint/destructiveHint/idempotentHint convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then approval, then forms, then guarantees — a sensible ordering with no filler paragraphs. It is on the long side and a few clauses are self-referentially dense ('raised unprompted in exactly one place, the close of that run, and never volunteered anywhere else'), which is prompting policy more than tool contract, but the density mostly buys real information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 15-parameter, nested-object, no-output-schema mutation tool, everything an agent must know is present: the two calling forms, required data per form, auth, approval gate, return values (URLs, trial share expiry), and the immutability/refusal model. Nothing needed to call it correctly is left to inference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning the schema cannot: it splits the 15 parameters into two mutually exclusive forms, names which fields each form requires (app_name, activities, jurisdictions, corpus_built_at, run_at for compact; a complete ungovr.lexlint-upload/1 record for full), and explains the triage fields' refusal rule. It does not fully disambiguate which parameters are ignored in which form (e.g. payload alongside compact fields), which keeps it off a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Store one lint run on the LexLint portal'), the account it lands under, and what comes back (portal URL, plus a 30-day share URL for trial keys). It also positions the tool in the lifecycle ('the closing step of every run that produced findings'), which separates it from run_lint and submit_feedback among the siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use (close of a run with findings, after developer approval), explicit when-not (never in a headless or CI session where nobody can approve), and explicit fallback behavior when the client asks nothing (the agent asks once itself). It also routes between the two calling modes and says to prefer the compact form.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources