osf-data-marketplace
Server Details
Verifiable public-domain US gov & scientific data for AI agents. Pay-per-record via x402 USDC.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 3 of 3 tools scored.
Each tool has a clearly distinct purpose: get_catalog for browsing free records, get_record for purchasing and retrieving a specific record, and screen_entity for sanctions checks. There is no overlap or ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case (get_catalog, get_record, screen_entity), making it easy to infer function.
Three tools is a reasonable number for a focused marketplace server covering browsing, purchasing, and a complementary paid service. The scope is well-defined, though a few more tools (e.g., for user management or additional filters) could be added without bloat.
The server covers the core workflow of browsing, filtering, purchasing records, and performing a sanctions screening. While additional features like transaction history or batch operations are missing, the surface addresses the primary use cases without dead ends.
Available Tools
5 toolsget_catalogAInspect
Browse the OSF catalog (FREE). Returns record_ids, prices, data types, and
provenance URLs so an agent can choose what to purchase. Optionally filter by
source (e.g. 'NVD', 'CISA_KEV', 'EPSS', 'GHSA', 'CWE', 'MITRE_ATTACK', 'SEC_EDGAR') or data_type (substring, e.g.
'CVE', 'Exploited', 'EPSS', '8-K', 'sanctions').
OSF aggregates verifiable public and openly-licensed U.S. government and
scientific data across many verticals: security and vulnerabilities
(CVE/KEV/EPSS/CWE/ATT&CK), sanctions and compliance (OFAC/EU/UK lists), SEC
and corporate filings (EDGAR/13F/10-K/XBRL), economic and financial
(FRED/BLS/BEA/Census/Treasury/World Bank), legal and regulatory (Federal
Register/eCFR/Congress/court opinions), grants and procurement
(USAspending/SAM/FEC/Grants.gov), science and research
(OpenAlex/PubMed/arXiv/Crossref/clinical trials), geospatial and environmental
(NOAA/USGS/EPA/FEMA), and AI/ML metadata (model hubs), among others. Every
record carries a provenance URL pointing back to its authoritative primary
source. Call get_record with a record_id to purchase the full record (x402
USDC micropayment on Base).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| source | No | ||
| data_type | No | ||
| record_key | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses read-only nature (FREE), what is returned (record_ids, prices, data types, provenance URLs), optional filtering, and the overall scope of data sources. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with purpose and key info, but includes a lengthy paragraph listing all data verticals that adds context but could be condensed. Overall adequate but not highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given optional parameters, presence of output schema, and sibling tool, description is comprehensive: it explains free browsing vs paid purchase, filtering options, range of data sources, and provenance. Agent has enough to decide when and how to invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. It explains source and data_type with examples, but fails to describe limit, offset, and record_key. Only 2 of 5 parameters are covered, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool browses the OSF catalog for free, returns record_ids and other fields, and distinguishes it from the sibling get_record tool (which purchases records). The verb 'browse' and resource 'OSF catalog' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: to browse the catalog for free. Also directs to use get_record for purchasing after finding a record_id. Provides clear context for choosing between the two tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_recordAInspect
Purchase and retrieve one verified OSF record by record_id (PAID, x402 USDC on Base). Returns the full record plus its provenance block linking back to the authoritative primary source (e.g. sec.gov, nvd.nist.gov, treasury.gov, congress.gov, ncbi.nlm.nih.gov, noaa.gov).
OSF spans many verticals: security/vulnerabilities, sanctions/compliance, SEC
and corporate filings, economic and financial series, legal and regulatory,
grants and procurement, science and research, geospatial and environmental, and
AI/ML metadata. Browse get_catalog first (free) to find record_ids and prices.
Payment is handled automatically by x402-capable MCP clients via the standard
payment handshake.
| Name | Required | Description | Default |
|---|---|---|---|
| record_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool involves a purchase (payment) and returns the record with provenance. No annotations provided, so description fully covers behavioral traits without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with core purpose. The third sentence on OSF verticals, while informative, is slightly tangential but not excessive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameter source, return contents (record + provenance), and payment handling. Lacks error handling details but is largely complete for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains record_id comes from get_catalog and is used to identify the record, adding critical meaning beyond the schema's minimal label.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a specific OSF record by record_id, with payment. It distinguishes from sibling get_catalog (browsing) by specifying purchase and retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use get_catalog first to find record_ids and prices, and mentions automatic payment via x402-capable MCP clients. Provides clear when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
is_cve_exploitedAInspect
Check whether a specific CVE is being actively exploited in the wild (PAID, x402 USDC on Base, $0.10). Pass a CVE id (e.g. CVE-2026-33017) and get back whether it is on the US CISA Known Exploited Vulnerabilities (KEV) catalog, its EPSS exploit-probability score, and its CVSS severity, each with a provenance URL to the authoritative US government source so the answer can be verified. For vulnerability management, patch prioritization, threat intelligence, and DevSecOps agent workflows. Payment is handled automatically by x402-capable MCP clients via the standard payment handshake.
| Name | Required | Description | Default |
|---|---|---|---|
| cve_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses the paid nature (x402, $0.10) and automatic payment handling. Does not mention side effects, but as a read-only check, none expected. Returns data with provenance URLs for verification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph covering purpose, usage, outputs, and payment. Could be slightly more front-loaded, but no wasted sentences. Information is compact and relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description clearly defines all return values (KEV status, EPSS score, CVSS severity, provenance URLs) and payment details. For a single-parameter tool, this is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage and only one parameter (cve_id). Description adds full meaning: expected format (e.g., CVE-2026-33017) and what the tool returns (CISA KEV, EPSS, CVSS, provenance). No other parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'check' and specific resource 'CVE', returns three specific pieces of data with provenance. Distinguishes from sibling tools like get_catalog (which likely returns catalog data) by focusing on exploit status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists use cases (vulnerability management, patch prioritization, etc.) and mentions payment requirements. Does not explicitly state when not to use or provide alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_entityAInspect
Verify an entity / counterparty by identifier or name (PAID, x402 USDC on Base, $0.10). Resolves against authoritative public registries: US healthcare providers (CMS NPI), global legal entities (GLEIF LEI), US banks (FDIC), and SEC filers / public companies (EDGAR CIK). Pass an identifier (NPI, LEI, FDIC cert, or CIK) for an exact match, or a name for candidate matches. Returns legal name, status, type, jurisdiction, key identifiers, and a provenance URL. For KYC, KYB, counterparty due-diligence, provider verification, and onboarding agent workflows. Payment is handled automatically by x402-capable MCP clients via the standard payment handshake.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses important behavioral traits: the tool resolves against specific registries, returns defined fields, and handles payment automatically via x402. It does not mention rate limits or error handling but provides sufficient context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, starting with the core purpose, then listing registries, query types, return fields, and use cases. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema and no output schema, the description covers inputs, registries, return fields, payment, and use cases. It could be improved by mentioning error handling or multiple match behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only one parameter 'query' with no description. The description compensates fully by explaining that query can be an identifier for exact match or a name for candidate matches, listing valid identifier types (NPI, LEI, etc.). This adds essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies an entity/counterparty by identifier or name against multiple authoritative registries. It distinguishes from siblings like get_catalog and screen_entity by specifying the data sources and use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use this tool (KYC, KYB, due-diligence, etc.) and explains how queries work (identifier for exact match, name for candidates). However, it does not explicitly contrast with screen_entity or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
screen_entityAInspect
Screen one entity or person name against international sanctions lists (PAID, x402 USDC on Base, $0.10). Checks OFAC SDN, EU Consolidated, and UK OFSI sanctions lists and returns potential-match / no-match with matched list, match basis, sanctions program/regime, a provenance URL to the official source, a compliance note, and a timestamped audit receipt. For AML, KYC, watchlist, OFAC, and sanctions-compliance agent workflows. Payment is handled automatically by x402-capable MCP clients via the standard payment handshake.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the screening process (checks specific lists, returns match/no-match with details), payment mechanism (x402), and result fields. Does not mention failure modes or rate limits, but sufficient for the tool's simplicity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is informative and front-loaded with main purpose. Includes pricing and payment which, while useful, slightly lengthens it. No redundant sentences; each part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 param, no output schema) and lack of annotations, the description comprehensively covers purpose, lists, output fields, use cases, and payment. No gaps for intended usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (name) with 0% schema description coverage. Description adds context by specifying it's an entity or person name, but does not provide format constraints or examples. Adequate but not exceptional for a simple string parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool screens a name against international sanctions lists, specifies the lists (OFAC SDN, EU Consolidated, UK OFSI), and indicates the output (potential-match/no-match with details). It distinguishes from siblings (get_catalog, get_record) which are unrelated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions use cases (AML, KYC, watchlist, OFAC, sanctions-compliance workflows). Does not explicitly state when not to use, but siblings are different, so no ambiguity. Includes payment details, which aids in usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!