Inteligencia empresarial en una sola llamada de herramienta. Obtenga perfiles de empresa completos — finanzas, pilas tecnológicas, competidores, patentes, personas clave, ofertas de empleo, inteligencia de dominio, presencia social y noticias — desde cualquier dominio o nombre de empresa. Agrega 12 fuentes de datos públicas gratuitas en paralelo. Funciona con Claude, ChatGPT, Cursor, Windsurf, Cline y cualquier cliente compatible con MCP.
Pruebe la demostración en vivo — introduzca cualquier nombre de empresa y vea resultados instantáneos. No se requiere registro.
¿Desea acceso alojado en la nube, siempre activo y con las 11 herramientas? Utilice el Apify Actor — pague solo por lo que usa, sin infraestructura que gestionar.
Herramienta | Descripción |
| Perfil completo de la empresa — información de fundación, descripción, pila tecnológica, personas clave, noticias, datos corporativos, finanzas |
| Detecta más de 19 frameworks, lenguajes, alojamiento y análisis desde el sitio web + GitHub |
| Encuentra fundadores, ejecutivos y miembros del equipo con sus cargos |
| Noticias recientes sobre una empresa |
| Datos del registro corporativo — constitución, jurisdicción, funcionarios (más de 140 países) |
| Datos financieros de SEC EDGAR — ingresos, ingresos netos, activos, pasivos, tickers bursátiles, presentaciones recientes |
| Descubra empresas competidoras mediante búsqueda web |
| Busque patentes de EE. UU. por cesionario de la empresa a través de Google Patents |
| Registros DNS, WHOIS/RDAP, proveedor de alojamiento, detección de servicio de correo electrónico |
| Puestos vacantes desde páginas de empleo — títulos, departamentos, ubicaciones |
| Redes sociales en 12 plataformas + estadísticas de la organización en GitHub |
Related MCP server: Brand Intelligence MCP
Utilice CompanyScope en Apify — siempre activo, pago por uso, sin configuración necesaria:
# 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"
]
}
}
}Descargue la extensión de CompanyScope y haga doble clic para instalarla en Claude Desktop. No se requiere configuración.
Conéctese al endpoint gratuito de 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"]
}
}
}Conecte CompanyScope directamente en ChatGPT — no requiere instalación:
Abra ChatGPT → Settings → Apps & Connectors → Advanced settings
Active Developer Mode (ON)
Haga clic en Add new connector
Introduzca:
Name: CompanyScope
URL: https://companyscope-mcp.stewwilli.workers.dev/mcp
Authentication: Seleccione No Auth
Marque "I trust this application" → Create
En cualquier chat, habilite Developer Mode y las 11 herramientas de CompanyScope estarán disponibles
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 deployTodos los datos se agregan de 10 fuentes públicas gratuitas — no se requieren claves API de pago:
Fuente | Datos proporcionados |
Wikipedia / Wikidata | Descripción de la empresa, año de fundación, sede, empleados, industria, ingresos, fundadores, CEO |
API de GitHub | Perfil de la organización, repositorios principales, lenguajes de programación, estrellas, colaboradores |
SEC EDGAR | Ingresos, ingresos netos, activos totales, pasivos, tickers bursátiles, presentaciones recientes |
Web scraping | Nombre de la empresa, descripción, pila tecnológica (más de 19 frameworks), enlaces sociales |
OpenCorporates | Fecha de constitución, jurisdicción, funcionarios registrados (más de 140 países) |
RDAP | Registrador de dominio, fecha de registro, servidores de nombres, antigüedad del dominio |
DNS (Cloudflare DoH) | Registros A, MX, NS, TXT; detección de proveedor de alojamiento y servicio de correo electrónico |
Brave Search | Descubrimiento de competidores, búsqueda de patentes, noticias de la empresa |
Google Patents | Patentes de EE. UU. por cesionario de la empresa — títulos, IDs, fechas |
Páginas de empleo | Ofertas de trabajo, departamentos, ubicaciones, detección de plataforma ATS |
> lookup_company("anthropic.com")Devuelve un perfil estructurado con:
Nombre de la empresa, descripción, industria
Fecha de fundación, sede, número de empleados
Pila tecnológica (desde el sitio web + GitHub)
Personas clave (desde el registro corporativo, sitio web, Wikipedia)
Noticias recientes
Perfiles sociales
Puntuación de confianza (0-1 basada en las fuentes de datos que devolvieron información)
Opción | Herramientas | Llamadas/Día | Precio |
Gratuito (Cloudflare) | 6 principales | 25 | $0 |
Gratuito (npm) | 6 principales | Ilimitado | $0 |
Las 11 | Ilimitado | Pago por uso |
Prospección de ventas — Investigue empresas objetivo antes de contactarlas. Obtenga la pila tecnológica, el tamaño del equipo y las finanzas.
Debida diligencia — Obtenga presentaciones de la SEC, registro corporativo y carteras de patentes en una sola llamada.
Inteligencia competitiva — Descubra competidores, compare pilas tecnológicas y actividad de contratación.
Flujos de trabajo de agentes de IA — Permita que su asistente de IA investigue y enriquezca datos de empresas de forma autónoma.
Apify Actor — Alojado en la nube, pago por uso, las 11 herramientas
npm — npx companyscope-mcp
Registro oficial de MCP — io.github.Stewyboy1990/companyscope-mcp
Smithery — Instalación con un clic
Glama — Puntuación 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.
