Skip to main content
Glama
diplv

companylens-mcp

by diplv
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

CompanyLens MCP Server

npm version License: MIT

Corporate intelligence for AI agents. Search companies, get SEC filings, screen sanctions, check government contracts — all via Model Context Protocol.

CompanyLens MCP gives your AI assistant access to real corporate data from official government sources. No web scraping, no hallucinations — verified data from SEC EDGAR, UK Companies House, OpenSanctions, and USAspending.gov.

Available Tools

Tool

Description

Data Source

company_search

Search companies by name or ticker

SEC EDGAR, Companies House

company_profile

Full corporate profile — financials, filings, officers, registration

SEC EDGAR, Companies House

company_sanctions_check

Screen against 75+ global sanctions lists

OpenSanctions (OFAC, EU, UN, HMT)

company_contracts

US government contracts and open opportunities

USAspending.gov, SAM.gov

company_court_cases

Federal court cases and litigation history

CourtListener / RECAP

Quick Start

Claude Desktop

claude mcp add companylens -- npx companylens-mcp

Claude Code (CLI)

Add to your project's .mcp.json:

{
  "mcpServers": {
    "companylens": {
      "command": "npx",
      "args": ["companylens-mcp"]
    }
  }
}

Cursor

Add to .cursor/mcp.json:

{
  "mcpServers": {
    "companylens": {
      "command": "npx",
      "args": ["companylens-mcp"]
    }
  }
}

Windsurf

Add to ~/.windsurf/mcp.json:

{
  "mcpServers": {
    "companylens": {
      "command": "npx",
      "args": ["companylens-mcp"]
    }
  }
}

Smithery

Install on Smithery

npx -y @smithery/cli install companylens-mcp --client claude

Usage Examples

Once connected, ask your AI assistant:

Company Research

  • "Search for Apple Inc and show me their latest SEC filings"

  • "Get the full profile for Microsoft — revenue, officers, SIC codes"

  • "Look up Rolls Royce in the UK Companies House registry"

Compliance & Risk

  • "Screen Gazprom against global sanctions lists"

  • "Check if this company has any OFAC matches"

  • "Run a sanctions check on all companies in my spreadsheet"

Government Contracts

  • "What government contracts does Boeing have?"

  • "Show me the top federal contracts for Lockheed Martin"

  • "Are there any open SAM.gov opportunities for this vendor?"

Legal Research

  • "Find federal court cases involving Tesla"

  • "What litigation history does Johnson & Johnson have?"

How It Works

AI Assistant  →  CompanyLens MCP  →  CompanyLens API  →  Government Sources
                  (this server)       (REST backend)      SEC, CH, OFAC, SAM.gov

  1. Your AI calls company_search with a company name

  2. CompanyLens searches official registries (SEC EDGAR, Companies House)

  3. Returns an entity_id — a stable identifier for that company

  4. Use the entity_id with other tools to get profile, sanctions, contracts, court cases

Every response includes an agent_hint — a natural-language suggestion for what the AI should do next.

Data Sources

Source

Coverage

Data

SEC EDGAR

US public companies

10-K, 10-Q filings, XBRL financials, SIC codes

Companies House

UK companies

Registration, officers, PSC, filing history

OpenSanctions

Global

OFAC SDN, EU Consolidated, UN Security Council, HMT + 75 lists

USAspending.gov

US federal

Contract awards, amounts, agencies

SAM.gov

US federal

Active opportunities, entity registration

CourtListener

US federal courts

Dockets, case metadata, RECAP archive

Configuration

Custom API URL

By default, the server connects to https://companylensapi.vercel.app. To use your own instance:

COMPANYLENS_API_URL=https://your-api.example.com npx companylens-mcp

Or in your MCP config:

{
  "mcpServers": {
    "companylens": {
      "command": "npx",
      "args": ["companylens-mcp"],
      "env": {
        "COMPANYLENS_API_URL": "https://your-api.example.com"
      }
    }
  }
}

Development

git clone https://github.com/diplv/companylens-mcp.git
cd companylens-mcp
pnpm install
pnpm dev

Build

pnpm build

Test with MCP Inspector

npx @modelcontextprotocol/inspector node dist/index.js

API Reference

company_search

Search companies by name or stock ticker.

Parameters:

  • query (string, required) — Company name or ticker (e.g., "Apple", "AAPL", "Rolls Royce")

  • jurisdiction (string, optional) — Filter: us, uk, or all (default: all)

  • limit (number, optional) — Max results 1-50 (default: 10)

Returns: List of companies with entity_id for use with other tools.

company_profile

Full corporate profile with financials and registration data.

Parameters:

  • entity_id (string, required) — CompanyLens entity ID from company_search

Returns: JSON with name, jurisdiction, status, SIC codes, registered address, XBRL financials (revenue, net income, total assets), recent filings, officers list, and data source attribution.

company_sanctions_check

Screen against global sanctions lists.

Parameters:

  • entity_id (string, required) — CompanyLens entity ID from company_search

Returns: Boolean is_sanctioned flag, match details with confidence scores, and list names. Includes a disclaimer that this is automated screening, not legal advice.

company_contracts

US government contract awards and opportunities.

Parameters:

  • entity_id (string, required) — CompanyLens entity ID from company_search

Returns: Awarded contracts (amount, agency, date) and open SAM.gov opportunities.

company_court_cases

Federal court litigation history.

Parameters:

  • entity_id (string, required) — CompanyLens entity ID from company_search

Returns: Court cases with case name, court, docket number, filing date, and status.

Related

License

MIT

Available Tools

5 tools
company_contractsGovernment ContractsA

Get US government contract data for a company: awarded contracts from USAspending.gov and open opportunities from SAM.gov. Use company_search first to get an entity_id.

ParametersJSON Schema
NameRequiredDescriptionDefault
entity_idYesCompanyLens entity ID from company_search (starts with "companylens_")

TDQS

A4/5.0
Behavior3/5

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

No annotations provided, so description carries full burden. It discloses data sources (USAspending.gov, SAM.gov) and data types (awarded contracts, open opportunities) but omits safety declarations (read-only status), error handling, or rate limits.

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?

Two efficiently structured sentences with zero waste: first establishes purpose and data provenance, second states the critical prerequisite. Information is front-loaded with the action verb.

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?

For a single-parameter tool, description adequately covers prerequisites and identifies return data categories (awarded contracts, open opportunities). Absence of output schema limits completeness regarding return structure, but description compensates by naming specific data sources.

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 coverage is 100% with complete parameter documentation, establishing baseline. Description references entity_id in workflow context but doesn't add semantic details (format, validation rules) beyond schema's explanation that it starts with 'companylens_'.

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 uses specific verb 'Get' with clear resource 'US government contract data' and distinguishes from siblings (company_court_cases, company_sanctions_check) by specifying the unique domain (USAspending.gov and SAM.gov data).

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?

Provides explicit prerequisite instruction 'Use company_search first to get an entity_id' establishing clear workflow sequence, though it lacks explicit 'when-not-to-use' exclusions or alternative tool recommendations.

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

company_court_casesCourt CasesA

Get US federal court cases involving a company — dockets, litigation history, case status. Powered by CourtListener/RECAP. Use company_search first to get an entity_id.

ParametersJSON Schema
NameRequiredDescriptionDefault
entity_idYesCompanyLens entity ID from company_search (starts with "companylens_")

TDQS

A3.9/5.0
Behavior3/5

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

Since no annotations are provided, the description carries the full burden. It successfully discloses the data source ('Powered by CourtListener/RECAP') and hints at return content ('dockets, litigation history, case status'). However, it omits operational details like read-only safety, pagination behavior, or rate limits that annotations would typically cover.

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?

Two sentences total, both information-dense. Front-loaded with purpose and scope, followed by prerequisite instruction. No redundant words or filler content. Every phrase earns its place in guiding the LLM.

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?

For a single-parameter lookup tool without output schema, the description adequately covers purpose, data provenance, return categories, and prerequisites. Minor gap: could explicitly state this retrieves historical litigation data to set expectations for the response structure.

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?

With 100% schema description coverage, the baseline is 3. The description adds valuable workflow context by stating the entity_id comes from company_search, helping the agent understand how to obtain valid parameter values. This meaningfully supplements the schema's technical description.

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

Purpose4/5

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

Description clearly states the tool retrieves 'US federal court cases involving a company' with specific outputs (dockets, litigation history, case status). The verb 'Get' is clear, and the scope (US federal) is specific. However, it does not explicitly differentiate from siblings like company_contracts or company_sanctions_check within the description text itself.

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?

Provides explicit prerequisite guidance: 'Use company_search first to get an entity_id,' establishing the required workflow sequence. This is strong context for when to invoke the tool. Lacks explicit 'when not to use' guidance or alternative tool suggestions for non-federal cases.

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

company_profileCompany ProfileA

Get a full corporate profile for a company: SEC filings, financials (revenue, net income, assets), UK registration details, officers. Use company_search first to get an entity_id.

ParametersJSON Schema
NameRequiredDescriptionDefault
entity_idYesCompanyLens entity ID from company_search (starts with "companylens_")

TDQS

A4/5.0
Behavior3/5

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

No annotations provided, so description carries full burden. Lists comprehensive data return types (behavioral outcome) but omits operational details: error handling (invalid entity_id), rate limits, caching behavior, or data freshness. Adequate for data scope disclosure but missing operational safety context.

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?

Two sentences, zero waste. First sentence front-loads specific data categories; second provides critical workflow prerequisite. Every word earns its place with no redundancy or generic filler.

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?

For a single-parameter lookup tool without output schema, description adequately compensates by enumerating return data categories. Missing explicit error scenarios or rate limit warnings, but covers essential usage pattern and data scope sufficiently for agent selection.

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 coverage is 100% with detailed parameter description. Description reinforces parameter provenance ('from company_search') which aids workflow understanding, but does not add technical constraints or format details beyond schema. Baseline 3 appropriate for high schema coverage.

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?

Specific verb ('Get') + resource ('corporate profile') with explicit data scope (SEC filings, financials, UK registration, officers). Clearly distinguishes from siblings by contrasting comprehensive profile data vs. specialized data (contracts, court cases, sanctions) and establishing dependency on company_search.

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 states prerequisite workflow ('Use company_search first to get an entity_id'), establishing clear sequence. Lacks explicit guidance on when to use sibling tools instead (e.g., for specific data types like contracts), but provides critical dependency information.

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

company_sanctions_checkSanctions ScreeningA

Screen a company against global sanctions lists (OFAC, EU, UN) via OpenSanctions. Returns match confidence scores. Use company_search first to get an entity_id. IMPORTANT: This is an automated screening, not a legal determination.

ParametersJSON Schema
NameRequiredDescriptionDefault
entity_idYesCompanyLens entity ID from company_search (starts with "companylens_")

TDQS

A4.4/5.0
Behavior4/5

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

No annotations provided, but description carries significant burden well: discloses data source (OpenSanctions), output format ('match confidence scores'), and critical legal disclaimer ('automated screening, not a legal determination'). Missing rate limits or error behaviors, but covers essential risk context for sanctions screening.

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?

Four sentences, zero waste: purpose/source, return value, prerequisite instruction, and legal disclaimer. Front-loaded with specific action, each sentence delivers unique essential information appropriate for a high-stakes compliance tool.

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?

Appropriate for low complexity (1 param). Compensates for missing annotations with legal disclaimer and output description ('match confidence scores'). No output schema exists, but description acknowledges return type. Could mention failure modes (no matches found), but adequate for tool complexity.

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% (entity_id fully documented), establishing baseline 3. Description adds valuable workflow context indicating the parameter must be obtained from company_search and hints at format ('companylens_'), exceeding baseline by providing usage semantics beyond static schema definitions.

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?

Excellent specificity: verb ('Screen'), resource ('company'), scope ('global sanctions lists OFAC, EU, UN'), and data source ('via OpenSanctions'). Clearly distinguishes from sibling tools by specifying sanctions-specific functionality versus contracts, court cases, or general profile/search.

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?

Strong prerequisite instruction ('Use company_search first to get an entity_id') establishes explicit workflow sequence with sibling tool. Lacks explicit 'when not to use' or alternative recommendations (e.g., when to use profile vs sanctions), but the dependency guidance is clear and actionable.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updatesv0.1.0
    • First observedcompany_contracts
    • First observedcompany_court_cases
    • First observedcompany_profile
    • First observedcompany_sanctions_check
    • First observedcompany_search
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Scored across 5 tools

Disambiguation5/5

Each tool targets a completely distinct data domain—search/indexing, financial/SEC profiles, government contracts, federal litigation, and sanctions screening. No functional overlap exists between the tools, making selection unambiguous.

Naming Consistency4/5

All tools follow the 'company_<resource>' snake_case pattern consistently. The minor deviation is that 'search' is an action/entry point while the others (profile, contracts, court_cases, sanctions_check) imply data retrieval, but the shared prefix and formatting keep it predictable.

Tool Count5/5

Five tools is ideal for this focused corporate intelligence domain. The set covers the essential due diligence workflow (search → profile/contracts/litigation/sanctions) without bloat or trivial fragmentation.

Completeness4/5

Covers the core compliance and intelligence lifecycle well: discovery via search, financial vetting via profile, legal risk via court cases, regulatory risk via sanctions, and business relationships via contracts. Minor gaps like news/media monitoring or beneficial ownership chains prevent a perfect score.

Resources

Related MCP Connectors

Appeared in Searches