单次工具调用即可获取公司情报。从任何域名或公司名称获取全面的公司简介——包括财务状况、技术栈、竞争对手、专利、关键人物、职位发布、域名情报、社交媒体表现和新闻。并行聚合 12 个免费公共数据源。适用于 Claude、ChatGPT、Cursor、Windsurf、Cline 以及任何兼容 MCP 的客户端。
尝试在线演示 — 输入任何公司名称即可查看即时结果。无需注册。
想要云托管、全天候运行且包含全部 11 个工具的访问权限？ 使用 Apify Actor — 按使用量付费，无需管理基础设施。
工具 | 描述 |
| 完整的公司简介 — 成立信息、描述、技术栈、关键人物、新闻、企业数据、财务状况 |
| 从网站 + GitHub 检测 19 种以上的框架、语言、托管和分析工具 |
| 查找带有职位的创始人、高管和团队成员 |
| 关于公司的最新新闻文章 |
| 企业注册数据 — 注册日期、司法管辖区、管理人员（140 多个国家/地区） |
| SEC EDGAR 财务数据 — 收入、净利润、资产、负债、股票代码、近期备案文件 |
| 通过网络搜索发现竞争公司 |
| 通过 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 → 设置 (Settings) → 应用与连接器 (Apps & Connectors) → 高级设置 (Advanced settings)
将 开发者模式 (Developer Mode) 切换为 ON
点击 添加新连接器 (Add new connector)
输入：
名称: CompanyScope
URL: https://companyscope-mcp.stewwilli.workers.dev/mcp
身份验证: 选择 无验证 (No Auth)
勾选“我信任此应用程序” → 创建 (Create)
在任何对话中，启用开发者模式，即可使用 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 | 收入、净利润、总资产、负债、股票代码、近期备案文件 |
网页抓取 | 公司名称、描述、技术栈（19 种以上框架）、社交链接 |
OpenCorporates | 注册日期、司法管辖区、注册管理人员（140 多个国家/地区） |
RDAP | 域名注册商、注册日期、名称服务器、域名年龄 |
DNS (Cloudflare DoH) | A、MX、NS、TXT 记录；托管服务商和电子邮件服务检测 |
Brave Search | 竞争对手发现、专利搜索、公司新闻 |
Google Patents | 按公司受让人分类的美国专利 — 标题、ID、日期 |
招聘页面 | 职位发布、部门、地点、ATS 平台检测 |
> lookup_company("anthropic.com")返回包含以下内容的结构化简介：
公司名称、描述、行业
成立日期、总部、员工人数
技术栈（来自网站 + GitHub）
关键人物（来自企业注册、网站、Wikipedia）
近期新闻
社交资料
置信度评分（0-1，基于返回数据的来源）
选项 | 工具 | 每天调用次数 | 价格 |
免费 (Cloudflare) | 6 个核心 | 25 | $0 |
免费 (npm) | 6 个核心 | 无限制 | $0 |
全部 11 个 | 无限制 | 按使用量付费 |
销售挖掘 — 在外联前研究目标公司。获取技术栈、团队规模、财务状况。
尽职调查 — 单次调用即可获取 SEC 备案文件、企业注册信息、专利组合。
竞争情报 — 发现竞争对手，比较技术栈和招聘活动。
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.
