Docs/Sources/Open Source License Grounding Data

Open Source License Grounding Data

Get information on open source licenses

OperationalCredits 2 per callp50 281msData Lookup

Overview

Pass any license name or identifier to retrieve its official metadata. The API checks the record and returns the full name, canonical URL, SPDX ID, legacy identifiers, and whether it is active, retired, or superseded. It also flags applicability across software, content, or data domains, with paid plans adding compatible domain details.

Live Test Open Source License Grounding Data Source →

The tool

Once your client is connected to the VerveContext server, this appears in its tool list as OpenSourceLicenseGroundingData. It is read-only and open-world — it fetches and never mutates anything on your side — so most clients call it without asking you to confirm.

Tool call
{
  "name": "OpenSourceLicenseGroundingData",
  "arguments": {
    "name": "MIT"
  }
}

You do not name the tool yourself; the model picks it. Asking about MIT in the terms this source covers is enough for it to reach for OpenSourceLicenseGroundingData on its own — naming it explicitly also works, and is the way to force the call.

Connecting

One server URL covers every source in the catalog, including this one. Authorization is OAuth: the client opens a browser once, and there is no key to paste into a config file.

{
  "mcpServers": {
    "vervecontext": {
      "url": "https://api.vervecontext.com/v1/mcp"
    }
  }
}

Per-client setup — Claude, Cursor, VS Code, ChatGPT — is on the MCP setup page.

Arguments

These are the properties on the tool's inputSchema, so a well-behaved client validates them before the call is made. Premium arguments are accepted on every plan but only take effect on plans that include them.

ArgumentTypeDescription
nameRequiredstringThe name of the open source license to get information about

What the model gets back

The result carries a structuredContent object matching the tool's declared outputSchema, so a client reads fields without parsing prose. status is "ok" and error is null on success; a null field means the value was not available for that input, not that the call failed.

Result
{
  "status": "ok",
  "error": null,
  "data": {
    "domain_content": false,
    "domain_data": false,
    "domain_software": true,
    "legacy_ids": [
      "mit-license"
    ],
    "license": "MIT",
    "name": "MIT License",
    "license_url": "https://opensource.org/licenses/MIT",
    "license_status": "active",
    "isOsiApproved": true,
    "compatibleDomains": [
      "software"
    ]
  }
}

Response fields

Paths are relative to data. Premium fields are absent rather than zeroed on plans that do not include them, so check for presence instead of comparing to 0.

FieldTypeExampleDescription
domain_contentbooleanfalseWhether the licence is intended for content
domain_databooleanfalseWhether the licence is intended for data
domain_softwarebooleantrueWhether the licence is intended for software
legacy_idsarray["mit-license"]Older identifiers this licence has been known by
licensestringMITSPDX identifier of the licence
namestringMIT LicenseFull name of the licence
license_urlstringhttps://opensource.org/licenses/MITCanonical URL of the licence text
license_statusstringactiveWhether the licence is active, retired or superseded
isOsiApprovedbooleantrueWhether the license is OSI approved
compatibleDomainsPremiumarray["software"]List of compatible domains (software, content, data)

Why ground on it

A model can produce something that looks like this answer from its training data, and be confidently out of date or simply wrong. This source returns the current value in a shape you can check, which is the difference between an answer you can cite and one you have to hedge.

Point an evaluation at domain_content: it is the field most worth pinning a claim to, and it is either present and current or absent — never plausibly invented.

Failure modes

Errors come back as tool errors carrying a sentence the model can act on, not a bare status code. Error handling covers the full list.

StatusWhat it means
400 / 422The arguments did not validate. The message names the offending one.
401The OAuth session is invalid or expired — reconnect the server.
403Blocked by a key restriction or an IP allow-list. Never a bad identity.
404This source is not part of VerveContext. Check the catalog.
429Out of credits, or a brief rate limit. The message tells them apart.

A call costs 2 credits each time the tool actually runs; a model that reasons about the tool without calling it costs nothing.

Use cases

Dependency Compliance Auditing
CI pipelines check third-party package licenses against OSI approval and active status flags before merging pull requests.
SBOM Metadata Enrichment
Software asset managers match SPDX identifiers and canonical URLs to internal components when assembling software bills of materials.
Package Registry Verification
When developers publish a package, code repositories verify that declared license names map to active SPDX IDs.
Dataset Ingestion Governance
Flag datasets governed by retired licenses or terms not meant for data before ingesting them into analytics environments.

Other ways to use Open Source License Grounding Data

Set up Open Source License Grounding Data on VerveContext, or reach the same source a different way. Your VerveContext account and credits work on all of them — one key, one balance.

Call it as a REST APIOne HTTPS endpoint and an x-api-key header, with SDKs for Node, Python and .NET.APIVerve →Reference →
Give it to an AI agentConnect over MCP and your agent calls it as a native tool — Claude, Cursor, ChatGPT.VerveKit →Reference →
Google Sheets or ExcelA =VERVE() formula fills a column — no script, no export, recalculates in place.VerveSheets →Reference →

More in Data Lookup:

Was this page helpful?