How do I use mcp-osint?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-osint Ukraine conflict news" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

mcp-osint

by DanDaDaDanDan

Overview Schema Related Servers Score Discussions

TypeScript

mcp-osint

MCP server for Claude Code providing access to OSINT data sources:

Government - Data.gov, LegiScan, CourtListener, Census Bureau
Research - OpenAlex, Semantic Scholar, PubMed, CORE
Corporate - SEC EDGAR (10-K, 10-Q), FRED (economic data)
Compliance - OpenSanctions (sanctions, PEPs)
News/Knowledge - GDELT, Wikidata
Infrastructure - crt.sh (SSL certificates, subdomains)
Web - Firecrawl (URL scraping with HTML + markdown)

Setup

1. Get API Keys

Required keys:

LegiScan - legiscan.com/user/register
CourtListener - courtlistener.com/api
FRED - fred.stlouisfed.org/docs/api
Firecrawl - firecrawl.dev

Optional keys (higher rate limits):

Data.gov - api.data.gov/signup
Census - census.gov/data/developers
CORE - core.ac.uk/services/api
OpenSanctions - opensanctions.org/api

Free (no key): SEC EDGAR, GDELT, Wikidata, crt.sh, OpenAlex, Semantic Scholar, PubMed

2. Install & Build

cd mcp-osint
npm install
npm run build

3. Add to Claude Code

Using the CLI:

claude mcp add -s user -t stdio mcp-osint \
  -e LEGISCAN_API_KEY=your-key \
  -e COURTLISTENER_API_KEY=your-key \
  -e FRED_API_KEY=your-key \
  -e FIRECRAWL_API_KEY=your-key \
  -- node /path/to/mcp-osint/dist/index.js

Or manually add to your MCP settings (~/.claude/settings.json or VS Code settings):

{
  "mcpServers": {
    "mcp-osint": {
      "command": "node",
      "args": ["/path/to/mcp-osint/dist/index.js"],
      "env": {
        "LEGISCAN_API_KEY": "your-key",
        "COURTLISTENER_API_KEY": "your-key",
        "FRED_API_KEY": "your-key",
        "FIRECRAWL_API_KEY": "your-key",
        "POLITE_EMAIL": "you@example.com"
      }
    }
  }
}

Related MCP server: OSINT MCP Server

Tools

osint_search

Search across 14 OSINT data sources. Returns results with available resources.

Parameter	Type	Required	Description
`query`	string	Yes	Natural language search query
`source`	string		Force a specific connector (see table below)
`jurisdiction`	string		State code (e.g., `"CA"`) or `"US"`
`year`	number		Filter to specific year
`limit`	number		Max results (default: 10)

Examples:

"EPA air quality data California"       → Data.gov
"Michigan renewable energy bill 2024"   → LegiScan
"Brown v. Board of Education"           → CourtListener
"population by county Texas"            → Census
"machine learning medical diagnosis"    → OpenAlex/PubMed
"Apple 10-K filing 2024"                → SEC EDGAR
"GDP quarterly growth rate"             → FRED
"Russian sanctions oligarchs"           → OpenSanctions
"Ukraine conflict news"                 → GDELT
"microsoft.com subdomains"              → crt.sh

osint_preview

Preview a resource's schema and sample data before fetching.

Parameter	Type	Required	Description
`resource_id`	string	Yes	Resource ID from osint_search
`row_limit`	number		Sample rows for tabular data (default: 5)
`max_bytes`	number		Max bytes for text preview (default: 4000)

osint_get

Fetch data from a resource ID or URL. Automatically handles web pages, PDFs, and structured data.

Parameter	Type	Required	Description
`target`	string	Yes	URL (http/https) or resource_id from osint_search
`output_path`	string		Path to save binary files (required for PDFs)
`question`	string		What to extract (e.g., "all data", "key findings")
`summarize`	boolean		If true with question, returns only relevant content (default: false)
`columns`	string[]		Specific columns to return (resource_id only)
`filters`	object[]		Filter conditions (resource_id tabular data only)
`limit`	number		Max rows for tabular data (default: 100)

Behavior by target type:

Target	Behavior
Web URL	Returns markdown + raw HTML + SHA256 hash via Firecrawl
PDF URL	Downloads to `output_path`, returns file path + SHA256
Binary URL	Downloads to `output_path`, returns file path + SHA256
Resource ID	Extracts data via connector with optional filtering

Examples:

osint_get target="https://example.com/article"
osint_get target="https://example.com/paper.pdf" output_path="./downloads/paper.pdf"
osint_get target="pubmed:paper:12345:abstract" question="key findings"

osint_list_sources

List all data sources and their configuration status.

Environment Variables

Variable	Required	Default	Description
`LEGISCAN_API_KEY`	Yes	-	LegiScan legislative data
`COURTLISTENER_API_KEY`	Yes	-	CourtListener judicial data
`FRED_API_KEY`	Yes	-	FRED economic data
`FIRECRAWL_API_KEY`	Yes	-	Firecrawl web scraping
`DATAGOV_API_KEY`		-	Data.gov (higher limits)
`CENSUS_API_KEY`		-	Census Bureau (higher limits)
`CORE_API_KEY`		-	CORE open access papers
`OPENSANCTIONS_API_KEY`		-	OpenSanctions compliance data
`POLITE_EMAIL`		-	Email for polite API usage (OpenAlex, PubMed, SEC)
`MCP_DEBUG`		`true`	Debug logging; set to `"false"` to disable
`MCP_LOG_DIR`		`./logs`	Log directory; set to `"none"` to disable

Connectors

Connector	Source	Data Types	Key Required
`data_gov`	Data.gov	Datasets, resources	Recommended
`legiscan`	LegiScan	Bills, votes, sponsors	Yes
`courtlistener`	CourtListener	Cases, opinions, dockets	Yes
`census`	Census Bureau	Demographics, statistics	Recommended
`openalex`	OpenAlex	Papers, authors, citations	No
`semantic_scholar`	Semantic Scholar	Papers, authors, citations	No
`pubmed`	PubMed/NCBI	Medical papers, abstracts	No
`core`	CORE	Open access papers	Recommended
`sec_edgar`	SEC EDGAR	10-K, 10-Q, company filings	No
`fred`	FRED	Time series, economic data	Yes
`opensanctions`	OpenSanctions	Sanctions, PEPs	Yes
`gdelt`	GDELT	News, global events	No
`wikidata`	Wikidata	Entities, knowledge graph	No
`crt_sh`	crt.sh	SSL certificates, subdomains	No

Development

npm install       # Install dependencies
npm run build     # Compile TypeScript
npm run dev       # Watch mode
npm start         # Run server

Testing

# Test connector metadata and identifiers
npx tsx test/test-all-connectors.ts

# Test data retrieval (downloads files)
npx tsx test/test-data-retrieval.ts

# Test Firecrawl HTML+Markdown
npx tsx test/test-firecrawl.ts

# Run comprehensive MCP tool tests
npx tsx test/test-mcp-scenarios.ts

Architecture

src/
├── index.ts              # MCP server entry point
├── types.ts              # Shared types
├── intent.ts             # Query parsing and routing
├── router.ts             # Connector selection
├── logger.ts             # Logging utility
├── cache.ts              # SQLite + file caching
├── retry.ts              # Retry with backoff
└── connectors/
    ├── base.ts           # Base connector class
    ├── data-gov.ts       # Data.gov/CKAN
    ├── legiscan.ts       # LegiScan
    ├── courtlistener.ts  # CourtListener
    ├── census.ts         # Census Bureau
    ├── openalex.ts       # OpenAlex
    ├── semantic-scholar.ts
    ├── pubmed.ts         # PubMed/NCBI
    ├── core.ts           # CORE
    ├── sec-edgar.ts      # SEC EDGAR
    ├── fred.ts           # FRED
    ├── opensanctions.ts  # OpenSanctions
    ├── gdelt.ts          # GDELT
    ├── wikidata.ts       # Wikidata
    ├── crt-sh.ts         # crt.sh
    └── firecrawl.ts      # Firecrawl

License

MIT

Available Tools

4 tools

osint_getA

Fetch data from a resource ID or URL.

Automatically handles:

URLs → web pages (markdown + raw HTML), PDFs (downloaded), binaries
Resource IDs → structured data from connectors with optional filtering

Always returns full raw content with SHA256 hash for verification. Use 'summarize: true' with a question to extract only relevant content.

For local archival, provide output_path:

Web pages: saves raw.html, content.md, links.json, metadata.json to output_path/
PDFs/binaries: saves file to output_path

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum rows for tabular data (default: 100)
`target`	Yes	URL (http/https) or resource_id from osint_search results
`columns`	No	Specific columns to return (resource_id tabular data only)
`filters`	No	Filter conditions (resource_id tabular data only)
`question`	No	What to extract (e.g., 'all data', 'rows for California', 'key findings')
`summarize`	No	If true with question, returns only relevant content. Default: false (full content).
`output_path`	No	Path to save files. For PDFs: file path. For web pages: directory path (saves raw.html, content.md, metadata.json).

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses automatic type detection, SHA256 hash verification, and summarize behavior. However, it omits important behavioral details: potential destructive actions (e.g., overwriting files via output_path), authentication requirements, rate limits, or what happens on error (e.g., broken links). This is adequate but not thorough.

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?

The description is well-structured with an opening line, bullet points for automatic handling, summary/archive instructions, and file format details. Every sentence adds value. It is slightly verbose in the archival section (three lines for web pages vs one for PDFs/binaries) but overall concise and front-loaded with the primary action.

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

Completeness3/5

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

Given the tool's complexity (7 parameters, no output schema, multiple input types), the description covers the main workflows: URL fetching, resource ID retrieval, summarization, and archival. However, it lacks details about the return format (e.g., raw JSON structure), error handling for invalid targets, and performance considerations for large files. It is complete for basic use but leaves gaps for edge cases.

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. The description adds significant value beyond the schema: it explains that 'target' can be a URL or resource_id, how 'summarize' with a question affects output, and what files 'output_path' saves for different types. This context helps the agent understand parameter usage better than the schema alone.

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?

The description starts with a clear verb-resource pair: 'Fetch data from a resource ID or URL.' It then explains two distinct modes (URLs and resource IDs) with specific handling for each. This differentiates it from siblings like osint_search and osint_list_sources, making the tool's purpose unmistakable.

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

Usage Guidelines4/5

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

The description provides clear context on when to use the tool: for URLs (web, PDF, binaries) and for resource IDs from osint_search. It offers practical guidance on using 'summarize' and 'output_path' parameters. However, it does not explicitly state when NOT to use the tool or name alternative tools for scenarios like simple previews (osint_preview).

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

osint_list_sourcesA

List all available OSINT data sources and their status.

Returns for each connector:

Name and health (healthy, degraded, unavailable)
API key configuration status
Required environment variable if missing

Use to check which sources are available before searching.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

No annotations provided, but description details output fields: name, health, API key status, missing env variable. Adequately discloses behavior for a read-only listing.

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

Conciseness5/5

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

Three sentences, front-loaded with purpose, no wasted words. Every sentence adds value.

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?

Given no parameters, no annotations, and no output schema, description fully covers what the tool returns and its usage context.

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?

No parameters in schema. Description adds no param info, but baseline is 4 for zero-parameter tools.

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?

Description clearly states 'List all available OSINT data sources and their status', specifying verb, resource, and scope. Differentiates from siblings by function.

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

Usage Guidelines4/5

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

Explicitly advises 'Use to check which sources are available before searching', providing clear context. Does not list exclusions or alternatives.

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

osint_previewA

Preview a resource's schema and sample data before fetching.

For tabular data: shows column names, types, and sample rows. For documents: shows text excerpt and structure. For APIs: shows available parameters and endpoints.

Use to confirm a resource has what you need before calling osint_get.

ParametersJSON Schema

Name	Required	Description
`max_bytes`	No	Max bytes for text preview (default: 4000)
`row_limit`	No	Sample rows for tabular data (default: 5)
`resource_id`	Yes	Resource ID from osint_search results

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries full burden and effectively explains what the tool returns for different data types (tabular, documents, APIs) and mentions default limits. It lacks details on error behavior or edge cases, but overall it provides sufficient transparency.

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

Conciseness5/5

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

The description is concise with just 6 lines, uses bullet points for clarity, and front-loads the main purpose. Every sentence adds value without redundancy.

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

Completeness4/5

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

Given the tool's moderate complexity (3 parameters, no output schema), the description covers the primary use case and different data type behaviors adequately. It lacks details on return format or error handling, but is sufficient for an agent to understand what to expect.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description mentions 'max_bytes for text preview' and 'row_limit for tabular data' but these do not add significant meaning beyond the already detailed schema descriptions.

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?

The description clearly states 'Preview a resource's schema and sample data before fetching' and elaborates on specific behaviors for tabular data, documents, and APIs. It distinguishes itself from sibling osint_get by explicitly advising to use it before fetching.

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

Usage Guidelines4/5

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

The description explicitly says 'Use to confirm a resource has what you need before calling osint_get,' providing clear context for when to use the tool. It also references osint_search in the parameter description. However, it does not specify when not to use it or list alternative tools beyond osint_get.

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

osint_searchA

Search across 14 OSINT data sources. Returns results with available resources.

Auto-routes to the best source, or use source to query a specific connector.

Sources: data_gov, legiscan, courtlistener, census, openalex, semantic_scholar, pubmed, core, sec_edgar, fred, opensanctions, gdelt, wikidata, crt_sh

Examples:

"EPA air quality data California" → Data.gov
"Michigan renewable energy bill 2024" → LegiScan
"Brown v. Board of Education" → CourtListener
"population by county Texas" → Census
"machine learning medical diagnosis" → OpenAlex/PubMed
"Apple 10-K filing 2024" → SEC EDGAR
"GDP quarterly growth rate" → FRED
"Russian sanctions oligarchs" → OpenSanctions
"Ukraine conflict news" → GDELT
"microsoft.com subdomains" → crt.sh

ParametersJSON Schema

Name	Required	Description
`year`	No	Filter to specific year
`limit`	No	Maximum results (default: 10)
`query`	Yes	Natural language search query
`source`	No	Search a specific connector (bypasses auto-routing)
`jurisdiction`	No	State code (e.g., 'CA', 'TX') or 'US' for federal

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description must convey all behavioral traits. It mentions auto-routing and returning 'results with available resources', but does not discuss rate limits, authentication, or any side effects. As a read-only search, this is minimally adequate but lacks depth.

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

Conciseness5/5

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

The description is well-structured and front-loaded: a succinct one-liner, followed by routing details, a list of sources, and practical examples. Every sentence serves a purpose, and the examples are particularly helpful without being excessive.

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

Completeness3/5

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

With 5 parameters and no output schema, the description covers the tool's purpose and source options adequately but leaves gaps: it does not specify return format for results, pagination behavior, or any prerequisites. For a search tool of this complexity, it is moderately complete but could be improved.

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% with clear descriptions for each parameter. The description adds significant value by providing concrete examples that illustrate how parameters like 'query' and 'source' interact, and maps natural language queries to appropriate sources, which aids the agent in parameter selection.

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?

The description clearly states 'Search across 14 OSINT data sources' with a specific verb and resource. The list of sources and examples strongly reinforce the tool's purpose, and it is easily distinguishable from siblings like osint_preview or osint_get.

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

Usage Guidelines4/5

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

The description explains auto-routing and how to use the 'source' parameter for specific connectors, which provides clear usage context. However, it does not explicitly contrast with sibling tools (e.g., when to use osint_search vs osint_preview), so it loses some points for direct alternatives.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a clear, non-overlapping purpose: listing sources, searching, previewing schemas, and fetching data. No ambiguity between them.

Naming Consistency5/5

All tools follow a consistent 'osint_verb' pattern (preview, list_sources, search, get), with predictable naming.

Tool Count5/5

Four tools cover the essential OSINT workflow (list, search, preview, get) without excess or deficiency.

Completeness5/5

The tool surface covers the full lifecycle: discover sources, search, preview data, and fetch. No obvious gaps for the intended use case.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Crimson Crawler
com.crimsoncrawler
Enrich, search, assess, and manage threat intelligence through 80+ typed MCP tools.
Security Search Research & Data
1
ahel
io.ahel
Hosted MCP server for real-world data: business registries, sanctions, companies, domains, crypto.
Government Data Cryptocurrency Open Data
2
sentrysurface
io.github.sentrysurface
Cybersecurity MCP server for URL scanning, threat intelligence, and domain reputation.
Security Penetration Testing
2
openfolio
io.github.dodenbach
Agent-native MCP server over 49M+ US public and government records, privacy-first, always current.
Government Data Open Data Search
1

Related MCP Servers

mcp-osint-server
Search Web Scraping Shell Access
himanshusanecha
F
license
Not graded
quality
D
maintenance
MCP server to perform various OSINT tasks by leveraging common network reconnaissance tools.
Updated a year ago (2025-03-12 16:44 UTC)
48
OSINT MCP Server
Security Search Research & Data
CloudWaddie
A
license
D
quality
D
maintenance
A comprehensive MCP server providing tools for IP, domain, email, and image-based open-source intelligence. It integrates services like Shodan, VirusTotal, and HaveIBeenPwned to facilitate advanced security research and data gathering.
Updated 6 months ago (2026-03-09 08:18 UTC)
56
48
ISC
omega-mcp-server
Penetration Testing Research & Data
Ekoelogan
A
license
Not graded
quality
D
maintenance
MCP server that exposes 108+ omega-cli OSINT tools for reconnaissance, web analysis, threat intelligence, and reporting, enabling AI assistants to perform comprehensive open-source intelligence tasks.
Updated 5 months ago (2026-04-01 03:17 UTC)
MIT
OSINT MCP Server
osintukraine
A
license
B
quality
D
maintenance
MCP server for the OSINT Intelligence Platform, enabling AI assistants to interact with Telegram intelligence archives via 65 tools for search, entity analysis, event tracking, social graph, and platform monitoring.
Updated 8 months ago (2025-12-25 20:08 UTC)
71
2
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/DanDaDaDanDan/mcp-osint'

If you have feedback or need assistance with the MCP directory API, please join our Discord server