単一のツール呼び出しで企業インテリジェンスを取得。あらゆるドメインや企業名から、財務、技術スタック、競合他社、特許、主要人物、求人情報、ドメインインテリジェンス、ソーシャルプレゼンス、ニュースなどの包括的な企業プロフィールを取得します。12の無料公開データソースを並列で集約します。Claude、ChatGPT、Cursor、Windsurf、Cline、およびMCP互換クライアントで動作します。
ライブデモを試す — 企業名を入力して、即座に結果を確認できます。サインアップは不要です。
11個のツールすべてを備えた、常時稼働のクラウドホスト型アクセスをご希望ですか？ Apify Actor をご利用ください。使用した分だけ支払う従量課金制で、インフラ管理は不要です。
ツール | 説明 |
| 完全な企業プロフィール — 設立情報、説明、技術スタック、主要人物、ニュース、企業データ、財務 |
| WebサイトとGitHubから19以上のフレームワーク、言語、ホスティング、分析を検出 |
| 創業者、役員、チームメンバーを役職付きで検索 |
| 企業に関する最近のニュース記事 |
| 企業登記データ — 設立日、管轄区域、役員（140カ国以上） |
| SEC EDGAR財務データ — 売上高、純利益、資産、負債、証券コード、最近の提出書類 |
| Web検索を通じて競合他社を発見 |
| Google Patentsを使用して、企業譲受人別に米国特許を検索 |
| DNSレコード、WHOIS/RDAP、ホスティングプロバイダー、メールサービス検出 |
| 採用ページからの求人情報 — 職種、部門、勤務地 |
| 12のプラットフォームにわたるソーシャルメディア + GitHub組織統計 |
Related MCP server: Brand Intelligence MCP
Apify でCompanyScopeを使用します — 常時稼働、従量課金、セットアップ不要:
# Claude Code
claude mcp add companyscope --transport http \
https://constructive-wainscot--companyscope-mcp.apify.actor/mcp \
--header "Authorization:Bearer YOUR_APIFY_TOKEN"// Claude Desktop (claude_desktop_config.json)
{
"mcpServers": {
"companyscope": {
"command": "npx",
"args": [
"mcp-remote",
"https://constructive-wainscot--companyscope-mcp.apify.actor/mcp",
"--header", "Authorization:Bearer YOUR_APIFY_TOKEN"
]
}
}
}CompanyScope拡張機能 をダウンロードし、ダブルクリックしてClaude Desktopにインストールします。設定は不要です。
無料のCloudflare Workersエンドポイントに接続します:
# Claude Code
claude mcp add companyscope --transport http https://companyscope-mcp.stewwilli.workers.dev/mcp// Claude Desktop
{
"mcpServers": {
"companyscope": {
"command": "npx",
"args": ["mcp-remote", "https://companyscope-mcp.stewwilli.workers.dev/mcp"]
}
}
}ChatGPTでCompanyScopeを直接接続します — インストール不要:
ChatGPT → 設定 → アプリとコネクタ → 詳細設定 を開く
開発者モード をONに切り替える
新しいコネクタを追加 をクリック
以下を入力:
名前: CompanyScope
URL: https://companyscope-mcp.stewwilli.workers.dev/mcp
認証: 認証なし を選択
「このアプリケーションを信頼します」にチェックを入れて → 作成
チャットで開発者モードを有効にすると、CompanyScopeの11個のツールが利用可能になります
npx companyscope-mcpgit clone https://github.com/Stewyboy1990/companyscope-mcp.git
cd companyscope-mcp && npm install
wrangler kv namespace create CACHE
# Update wrangler.toml with your KV namespace ID
npm run deployすべてのデータは10の無料公開ソースから集約されています — 有料のAPIキーは不要です:
ソース | 提供データ |
Wikipedia / Wikidata | 企業説明、設立年、本社、従業員数、業界、売上高、創業者、CEO |
GitHub API | 組織プロフィール、主要リポジトリ、プログラミング言語、スター数、貢献者 |
SEC EDGAR | 売上高、純利益、総資産、負債、証券コード、最近の提出書類 |
Webスクレイピング | 企業名、説明、技術スタック（19以上のフレームワーク）、ソーシャルリンク |
OpenCorporates | 設立日、管轄区域、登録役員（140カ国以上） |
RDAP | ドメイン登録機関、登録日、ネームサーバー、ドメイン年齢 |
DNS (Cloudflare DoH) | A、MX、NS、TXTレコード、ホスティングプロバイダーおよびメールサービスの検出 |
Brave Search | 競合他社の発見、特許検索、企業ニュース |
Google Patents | 企業譲受人別の米国特許 — タイトル、ID、日付 |
採用ページ | 求人情報、部門、勤務地、ATSプラットフォームの検出 |
> lookup_company("anthropic.com")以下を含む構造化されたプロフィールを返します:
企業名、説明、業界
設立日、本社、従業員数
技術スタック (Webサイト + GitHubより)
主要人物 (企業登記、Webサイト、Wikipediaより)
最近のニュース
ソーシャルプロフィール
信頼度スコア (データを返したデータソースに基づく0〜1の数値)
オプション | ツール | 1日の呼び出し回数 | 価格 |
無料 (Cloudflare) | 6つのコアツール | 25 | $0 |
無料 (npm) | 6つのコアツール | 無制限 | $0 |
全11ツール | 無制限 | 従量課金 |
営業見込み客の発掘 — アプローチ前にターゲット企業を調査。技術スタック、チーム規模、財務状況を取得。
デューデリジェンス — SEC提出書類、企業登記、特許ポートフォリオを1回の呼び出しで取得。
競合インテリジェンス — 競合他社を発見し、技術スタックや採用活動を比較。
AIエージェントワークフロー — AIアシスタントに自律的に企業データを調査・拡充させる。
Apify Actor — クラウドホスト型、従量課金、全11ツール
npm — npx companyscope-mcp
公式MCPレジストリ — io.github.Stewyboy1990/companyscope-mcp
Smithery — ワンクリックインストール
Glama — AAAスコア
MIT
Get recent news articles about a company from Brave Search and NewsAPI. Returns article titles, descriptions, sources, and publication dates sorted by recency. Use company name, not domain. Coverage depends on server-side API key configuration.
| Name | Required | Description | Default |
|---|---|---|---|
| company_name | Yes | Company name as it would appear in news articles (e.g. 'Anthropic', 'OpenAI', 'Tesla'). Do not pass a domain. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses returned data (titles, descriptions, sources, dates sorted by recency) and the dependency on server-side API key configuration. No annotations provided, but description adequately covers behavioral expectations.
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: purpose and sources, returned fields, usage note + caveat. Every sentence earns its place; no 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?
For a simple news-fetching tool with one parameter and no output schema, the description covers input requirements, return content, sorting, and external dependencies. No critical gaps.
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 covers 100% of the single parameter with description. Description adds value by providing examples ('Anthropic', 'OpenAI', 'Tesla') and reinforcing the 'not domain' constraint, exceeding baseline.
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 'Get recent news articles about a company' with specific sources (Brave Search and NewsAPI). Precisely describes the action and resource, distinguishing it from sibling tools that handle corporate registry, financials, or people.
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 instructs to use company name, not domain, and mentions API key dependency. Lacks explicit guidance on when to prefer this tool over alternatives, but context is sufficiently implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up corporate registry data from OpenCorporates — incorporation date, status, jurisdiction, registered address, and company officers. Covers companies in 140+ jurisdictions worldwide. Use the company's legal name for best results. Note: this may return no results for very new or small private companies.
| Name | Required | Description | Default |
|---|---|---|---|
| company_name | Yes | Company legal name as registered (e.g. 'Stripe, Inc.', 'Alphabet Inc.'). Legal names with suffixes like Inc/Ltd/GmbH produce more accurate results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Discloses potential no-results, but does not mention rate limits, data freshness, or auth requirements. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences; purpose is front-loaded. No superfluous words. Efficient and structured.
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 enumerates returned data fields (incorporation date, etc.) and covers edge case (no results). Sufficient for a simple lookup 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 covers 100% of the single parameter with clear description. Description adds value by suggesting suffixes improve accuracy, going beyond schema details.
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 lookup of corporate registry data from OpenCorporates, specifying data types (incorporation date, status, etc.) and coverage (140+ jurisdictions). Distinguishes from siblings like get_financials or get_key_people.
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?
Provides best practice (use legal name) and acknowledges possible no-results for new/small companies, but does not explicitly contrast with sibling tools or state when to prefer this over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get financial data for US public companies from SEC EDGAR filings. Returns revenue, net income, total assets, total liabilities, stockholders' equity, stock exchange tickers, SIC industry code, and recent SEC filings (10-K, 10-Q, 8-K). Only works for companies that file with the SEC — private companies and non-US companies will return no results. Data is updated as companies file new reports.
| Name | Required | Description | Default |
|---|---|---|---|
| company_name | Yes | Company name or stock ticker symbol (e.g. 'Apple', 'AAPL', 'Tesla', 'MSFT'). Both common names and ticker symbols are supported. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses data sources (SEC EDGAR), scope (US public companies), and data freshness ('updated as companies file new reports'), which is adequate for a read-only data retrieval tool.
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 (three sentences), front-loaded with the core purpose, and every sentence adds value. No redundancy or fluff.
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?
With one simple parameter, no output schema, and clear scope, the description fully explains what the tool does, what data it returns, and its limitations. No additional information is needed.
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 single parameter 'company_name' is well-described in the schema (100% coverage). The description adds that both common names and ticker symbols are supported, which enhances semantic understanding 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 it gets financial data for US public companies from SEC EDGAR, listing specific fields (revenue, net income, etc.). This distinguishes it from sibling tools like get_company_news (news) or get_corporate_registry (registry info).
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 explicitly limits use to SEC-filing companies, stating private and non-US companies will return no results. It gives clear context but does not explicitly mention alternatives to this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find key people at a company including founders, C-suite executives, and team members. Scrapes the company's website (e.g. /about, /team pages), checks Wikipedia, and cross-references GitHub org members. Returns names, titles, and sources. Use this when you need leadership or team information specifically. Requires a domain name.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Company website domain without protocol (e.g. 'openai.com'). The tool will scrape the site's about/team pages. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the scraping process (website, Wikipedia, GitHub), the data returned (names, titles, sources). With no annotations, this is sufficient behavioral disclosure. Could be improved by mentioning potential failure modes or rate limits, but overall transparent.
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 concisely cover purpose, method, use case, and requirement. No extraneous words. Front-loaded with the main action.
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 a single parameter and no output schema, the description covers the essential aspects: input, process, output, and use case. It could be more complete by mentioning limitations (e.g., only public info, or if site blocks scraping), but it's largely adequate.
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 covers the single parameter 'domain' at 100%. The description adds further context: 'without protocol (e.g. 'openai.com')' and explains how the domain is used (scraping about/team pages). This adds value 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?
Clearly defines the tool as finding key people (founders, C-suite, team members) at a company. Differentiates from sibling tools like get_company_news or get_financials by focusing specifically on leadership and team information.
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 states when to use: 'when you need leadership or team information specifically.' Also specifies a prerequisite: 'Requires a domain name.' Does not provide explicit exclusions or alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect a company's technology stack by analyzing HTTP headers, DNS records, and GitHub repositories. Returns frameworks, programming languages, hosting providers, analytics tools, and CDNs. Use this instead of lookup_company when you only need technology information. Requires a domain name — company names are not supported for this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Company website domain without protocol (e.g. 'vercel.com', 'github.com'). Must be a valid domain, not a company name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the analysis methods (HTTP headers, DNS, GitHub) and return content, but does not mention any side effects, rate limits, or authentication requirements. Since no annotations are provided, the description carries the full burden; it is mostly transparent but lacks explicit safety or non-destructive confirmation.
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 three sentences, each adding distinct value: purpose and method, usage guidance and return types, and input constraint. No unnecessary words, front-loaded with key information.
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 low complexity (1 parameter), full schema coverage, and no output schema, the description compensates by listing return types (frameworks, languages, etc.) and providing clear usage context. It is complete for an agent to correctly invoke the 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?
With 100% schema coverage, the input schema already describes the 'domain' parameter adequately. The description reinforces the requirement but adds no new semantic meaning beyond confirming domain format and exclusion of company names.
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 explicitly states 'Detect a company's technology stack' with specific methods (HTTP headers, DNS, GitHub) and return types (frameworks, languages, etc.). It distinguishes itself from the sibling 'lookup_company' tool, making the purpose clear and unique.
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 provides explicit guidance: 'Use this instead of lookup_company when you only need technology information' and 'Requires a domain name — company names are not supported.' This covers when to use, when not to, and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a comprehensive company profile by aggregating data from Wikipedia, GitHub, SEC EDGAR, OpenCorporates, and web scraping. Returns founding year, description, headquarters, employee count, industry, tech stack, key people, and recent news. Use this as the primary entry point for any company research — it calls all other data sources automatically. Input can be a domain (stripe.com) or company name (Stripe). Returns a JSON object with confidence scores and source attribution.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Company domain (e.g. 'stripe.com') or company name (e.g. 'Stripe'). Domains produce richer results because they enable website scraping and DNS analysis. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behavioral traits: it aggregates data from multiple sources, returns JSON with confidence scores and source attribution, and notes that domains produce richer results. It could mention potential latency or failure modes, but overall is transparent enough.
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 four sentences, each serving a purpose: purpose and sources, return fields, usage guidance, input format and note. No fluff, and critical information is front-loaded.
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 complexity and lack of output schema, the description adequately covers input format, output structure (fields, confidence scores, source attribution), and usage context. It equips the agent to understand what the tool returns and when to invoke it.
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 100% with one parameter. The description adds valuable context beyond the schema: 'Domains produce richer results because they enable website scraping and DNS analysis.' This helps an agent choose between domain or company name.
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's purpose: 'Get a comprehensive company profile by aggregating data from multiple sources.' It lists specific return fields and distinguishes itself from sibling tools by being the primary entry point that calls other data sources automatically.
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?
Explicit guidance: 'Use this as the primary entry point for any company research — it calls all other data sources automatically.' This tells the agent when to use this tool versus the more specific sibling tools like get_financials or get_tech_stack.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_company_newsget_corporate_registryget_financialsget_key_peopleget_tech_stacklookup_companyScored across 6 tools
Tools are mostly distinct, but lookup_company aggregates data from the other tools, creating potential overlap. Specialized tools have specific input constraints (e.g., domain vs. name), so they remain useful, but an agent might default to lookup_company and miss targeted functionality.
All tool names follow a consistent verb_noun pattern (get_*, lookup_*), with clear and descriptive nouns. The slight variation in verb ('get' vs 'lookup') is minor and does not hinder readability.
With 6 tools covering distinct aspects of company research (news, registry, financials, people, tech stack, comprehensive), the set is well-scoped without being overwhelming or insufficient.
The set covers core company data but has notable gaps: financials are limited to US public companies, and there is no tool for non-US private company financials or competitor analysis. The comprehensive lookup mitigates some gaps but cannot fill all.
Company enrichment for AI agents: firmographics, tech stack, headcount, funding, domain emails.
Free company data for AI agents: profiles, tech stacks, contact details and people. No sign-in.
Company profile lookup and B2B company search for AI agents.
Global B2B intelligence for AI agents: 35M+ companies, 1.6M sanctions, KYB pack. 78 tools.
