Allows comprehensive company research on Figma including overview, products, financials, funding, leadership, culture, and more.
Allows comprehensive company research on HubSpot including overview, products, financials, funding, leadership, culture, and more.
Allows comprehensive company research on Notion including overview, products, financials, funding, leadership, culture, and more.
Allows comprehensive company research on OpenAI including overview, products, financials, funding, leadership, culture, and more.
Allows comprehensive company research on Stripe including overview, products, financials, funding, leadership, culture, and more.
Allows comprehensive company research on Vercel including overview, products, financials, funding, leadership, culture, and more.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Linkup Company Research MCP Give me an overview of Stripe"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that provides comprehensive company research tools powered by Linkup. Connect it to Claude, Cursor, or any MCP-compatible client to get instant company intelligence.
17 research tools covering all aspects of company intelligence
Dual output formats: Natural language answers with sources, or structured JSON for automation
Full parameter control: Date filters, domain filters, image support, and result limits
Optimized prompts: Following Linkup's best practices for accurate, comprehensive research
Related MCP server: MCP Research Server
Tool | Description | Search Depth |
| Company identity, location, size, industry, business model | Deep |
| Products, services, pricing, and use cases | Standard |
| Revenue streams, unit economics, go-to-market strategy | Standard |
| Ideal customer profile, segments, geographic markets | Standard |
| Revenue, profitability, key metrics (ARR, MRR, GMV, NRR) | Deep |
| Funding rounds, valuation, investors | Deep |
| CEO, C-suite, founders, board members, key hires | Standard |
| Glassdoor ratings, work policy, benefits, employer brand | Standard |
| Customers, case studies, testimonials | Deep |
| Strategic partners, integrations, ecosystem | Deep |
| Tech stack, patents, R&D, open source contributions | Deep |
| Competitors, market position, differentiators | Deep |
| Industry context, TAM/SAM/SOM, trends, regulations | Deep |
| Latest news, product launches, announcements | Standard |
| Growth plans, expansion, M&A history, IPO signals | Deep |
| Risk assessment across competitive, regulatory, legal dimensions | Deep |
| ESG initiatives, sustainability, reputation, controversies | Standard |
All tools support two output formats via the output_format parameter:
output_format="answer")Returns a comprehensive answer with up to 5 cited sources. Best for human consumption.
output_format="structured")Returns data in a defined JSON schema. Best for automation, CRM integration, and data pipelines.
Parameter | Type | Description |
| str | Required. The company to research |
| str |
|
| int | Maximum sources to consider (1-50, default: 10-15) |
Parameter | Type | Description |
| str | Start date in YYYY-MM-DD format |
| str | End date in YYYY-MM-DD format |
Parameter | Type | Description |
| str | Comma-separated domains to include (e.g., "techcrunch.com,reuters.com") |
| str | Comma-separated domains to exclude |
Parameter | Type | Tools | Description |
| bool | overview, competitive_landscape, leadership | Include relevant images |
| str | news | Filter by topic (e.g., "funding", "product launch") |
| str | products | Filter for a specific product |
Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"linkup-company-research": {
"command": "uvx",
"args": ["linkup-company-research-mcp"],
"env": {
"LINKUP_API_KEY": "your-api-key-here"
}
}
}
}claude mcp add linkup-company-research -- uvx linkup-company-research-mcpThen set your API key:
export LINKUP_API_KEY="your-api-key-here"Add to .cursor/mcp.json in your project:
{
"mcpServers": {
"linkup-company-research": {
"command": "uvx",
"args": ["linkup-company-research-mcp"],
"env": {
"LINKUP_API_KEY": "your-api-key-here"
}
}
}
}Go to linkup.so
Sign up or log in
Navigate to API settings
Generate your API key
Once connected, you can ask your AI assistant things like:
"Give me an overview of Stripe"
"What's the latest news about OpenAI?"
"Who are Figma's main competitors?"
"Get Anthropic's funding news from the last 6 months" (date filter)
"Find Notion's customers and case studies"
"What tech stack does Vercel use?"
"Get Stripe's company overview in structured format" (returns JSON)
"Research HubSpot's leadership team as JSON" (for CRM integration)
Researches the company's website, LinkedIn, and press coverage to provide detailed information about what they do, their industry, size, and business model.
Researches product pages, pricing, and documentation to provide detailed information about offerings, pricing models, and use cases.
Researches how the company makes money, their revenue streams, unit economics, and go-to-market strategy.
Researches the company's ideal customer profile, customer segments, geographic markets, and vertical focus.
Researches revenue, profitability, key business metrics (ARR, MRR, GMV, NRR), and financial health indicators.
Researches funding history, funding rounds, valuation, and investors through Crunchbase, PitchBook, press releases, and financial news.
Identifies CEO, C-suite executives, founders, board members, key hires, and notable departures.
Researches Glassdoor ratings, employer awards, culture attributes, work policy (remote/hybrid/in-office), and benefits.
Researches customer pages, case studies, press releases, and review sites to identify verified customers and their use cases.
Researches partner pages, integration marketplaces, press releases, and partner programs to map the company's ecosystem.
Analyzes engineering blogs, job postings, tech detection tools, patents, and open source contributions to understand technical capabilities.
Identifies competitors, market positioning, differentiators, and competitive advantages through research of industry reports, review sites, and company materials.
Researches industry classification, market size (TAM/SAM/SOM), industry growth rate, market trends, and regulatory environment.
Searches news sources, press releases, and publications for recent coverage including product launches, funding, partnerships, and M&A activity.
Researches growth strategy, expansion plans (geographic, product, vertical), M&A history, acquisition rumors, and IPO signals.
Researches competitive risks, regulatory risks, legal exposure, key person dependency, customer concentration, technology risks, and market risks.
Researches ESG initiatives, sustainability commitments, environmental programs, social initiatives, governance, controversies, and brand perception.
# Clone and install locally
git clone https://github.com/LinkupPlatform/linkup-company-research-mcp
cd linkup-company-research-mcp
pip install -e .
# Run the server directly
LINKUP_API_KEY="your-key" linkup-company-researchsrc/linkup_company_research/
├── __init__.py
├── server.py # Main MCP server with 17 tools
├── schemas.py # JSON schemas for structuredOutput
├── prompts.py # Optimized prompt templates
└── types.py # Type definitionsMIT
Get information about a company's business model.
Researches how the company makes money, their revenue streams, unit economics, and go-to-market strategy.
Args: company_name: The name of the company to research output_format: "answer" for natural language with sources, "structured" for JSON max_results: Maximum number of sources to consider (1-50)
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | ||
| company_name | Yes | ||
| output_format | No | answer |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The phrase 'Get information' implies a read-only operation, but it does not explicitly state non-destructiveness, authentication requirements, or rate limits. The description adds some context about the research scope but lacks explicit safety guarantees.
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 brief (5 lines) and front-loaded with the purpose. Every sentence adds value: purpose, research scope, then parameter docs. No redundant or vague wording.
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 presence of an output schema (not shown but signaled), the description appropriately omits return value details. It covers the research scope and all parameters. Missing explicit usage guidelines, but otherwise complete for a straightforward retrieval 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 description coverage is 0%, so the description must explain parameters. The Args section fully describes 'company_name', 'output_format' (with options), and 'max_results' (with range). This adds significant meaning beyond the schema's minimal titles and types.
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 'Get information about a company's business model' and details what it researches (revenue streams, unit economics, go-to-market strategy). This distinguishes it from sibling tools which focus on other aspects like clients, financials, or products.
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 tells what the tool covers (business model research) but does not explicitly state when to use it versus alternatives like 'company_financials' or 'research_company'. No exclusions or conditions are provided, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find known clients, customers, and case studies for a company.
Researches customer pages, case studies, press releases, and review sites to identify verified customers and their use cases.
Args: company_name: The name of the company to research output_format: "answer" for natural language with sources, "structured" for JSON max_results: Maximum sources to consider (1-50)
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | ||
| company_name | Yes | ||
| output_format | No | answer |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It implies a read-only operation ('researches') but does not explicitly state that it only reads public data, does not modify anything, or any associated rate limits. The return format is mentioned ('natural language with sources' or 'JSON') but details are likely covered by the output schema. Overall, adequate but not explicit.
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: two sentences for purpose/sources, followed by a clean Args list. Every part adds value. No irrelevant details or repetition.
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 has 3 parameters, an output schema, and many siblings, the description is nearly complete. It covers purpose, sources, and parameters. Missing elements are usage guidelines (when/why to use) and a note that output schema details are available. Still, it provides sufficient context for an agent to use it correctly.
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 description's 'Args:' section fully explains each parameter: company_name, output_format (with allowed values 'answer' or 'structured'), and max_results (range 1-50). This compensates for the 0% schema description coverage by adding clear meaning beyond the schema's titles and types.
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: 'Find known clients, customers, and case studies for a company.' It specifies the verb (research) and the resources (clients/case studies). This distinguishes it from sibling tools like company_products or company_partnerships, which focus on different aspects.
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 does not explicitly state when or when not to use this tool. There is no comparison with alternatives or mention of prerequisites. While the purpose is clear, the lack of usage guidance means the agent may not know whether to choose this over similar tools like company_products or research_company.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a company's culture and employer reputation.
Researches Glassdoor ratings, employer awards, culture attributes, work policy (remote/hybrid/in-office), and benefits.
Args: company_name: The name of the company to research output_format: "answer" for natural language with sources, "structured" for JSON max_results: Maximum sources to consider (1-50)
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | ||
| company_name | Yes | ||
| output_format | No | answer |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose behavioral traits such as data freshness, latency, or failure modes. The description focuses on function and parameters, omitting important behavioral context for a 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?
Description is reasonably structured but somewhat verbose with a full docstring including parameter docs. Front-loaded summary is effective, but some redundancy exists (e.g., listing items in the first paragraph and then parameter docs).
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 presence of an output schema, the description adequately covers the tool's functionality and parameter semantics. It lacks mention of error conditions or prerequisites, but for a retrieval tool with clear parameters, it is largely complete.
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 0%, but the description's Args section provides clear explanations for all three parameters: company_name, output_format (with meaning of options), and max_results (with range). This adds significant value beyond schema types and defaults.
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?
Description clearly states the tool retrieves company culture and employer reputation, listing specific data sources like Glassdoor ratings, awards, and work policy. This distinguishes it from sibling tools that cover other company aspects.
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?
No explicit guidance on when to use this tool versus alternative company tools (e.g., company_overview, company_leadership). Agent must infer usage from the tool's purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get ESG and reputation information about a company.
Researches ESG initiatives, sustainability commitments, environmental programs, social initiatives, governance, controversies, and brand perception.
Args: company_name: The name of the company to research output_format: "answer" for natural language with sources, "structured" for JSON max_results: Maximum sources to consider (1-50)
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | ||
| company_name | Yes | ||
| output_format | No | answer |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the tool as researching and providing sources, implying read-only behavior. With no annotations, it could be more explicit about non-destructive nature and any data sources or limits beyond max_results.
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?
Well-structured with clear description and Args section. Some redundancy in listing ESG aspects, but overall concise and 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?
Output schema exists, so return value explanation is not needed. Description covers all parameters and tool purpose adequately for the domain, though usage context could be stronger.
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?
Provides meaningful explanations for each parameter, especially output_format (answer vs structured) and max_results range. Schema coverage is 0%, so description adds significant value beyond 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 states it gets ESG and reputation information, listing specific aspects like sustainability, governance, controversies. Distinguishes from siblings like company_overview or research_company by focusing on ESG.
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?
No guidance on when to use this tool vs alternatives. Does not mention when it is appropriate or when to avoid (e.g., for non-ESG queries).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get financial information about a company.
Researches revenue, profitability, key business metrics (ARR, MRR, GMV, NRR), and financial health indicators.
Args: company_name: The name of the company to research output_format: "answer" for natural language with sources, "structured" for JSON from_date: Start date for financial news (YYYY-MM-DD) to_date: End date for financial news (YYYY-MM-DD) max_results: Maximum sources to consider (1-50)
| Name | Required | Description | Default |
|---|---|---|---|
| to_date | No | ||
| from_date | No | ||
| max_results | No | ||
| company_name | Yes | ||
| output_format | No | answer |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that outputs can include sources ('natural language with sources') but does not mention side effects, rate limits, data freshness, or permissions. It is adequate but not rich.
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 well-structured with a concise summary followed by an Args block. It is efficient and front-loads the purpose, though the Args section could be slightly more integrated.
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 presence of an output schema (not shown but indicated), return values are covered. The description explains the input parameters and output formats. It does not mention edge cases or limitations, but is complete enough for a straightforward research 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 description coverage is 0%, but the description includes a detailed Args section explaining all five parameters, their types, formats, and defaults (e.g., 'output_format: answer for natural language with sources, structured for JSON'). This fully compensates for the schema's lack of descriptions.
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 'Get financial information about a company' and lists specific metrics (revenue, profitability, ARR, MRR, etc.), distinguishing it from sibling tools that focus on other aspects like business model, culture, or leadership.
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 implicitly indicates usage for financial research through its domain focus, but lacks explicit guidance on when to use vs. alternatives or prerequisites. The sibling tools are distinct, so confusion is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get funding and valuation information about a company.
Researches funding history, funding rounds, valuation, and investors through Crunchbase, PitchBook, press releases, and financial news.
Args: company_name: The name of the company to research output_format: "answer" for natural language with sources, "structured" for JSON from_date: Start date for funding news (YYYY-MM-DD) to_date: End date for funding news (YYYY-MM-DD) max_results: Maximum sources to consider (1-50)
| Name | Required | Description | Default |
|---|---|---|---|
| to_date | No | ||
| from_date | No | ||
| max_results | No | ||
| company_name | Yes | ||
| output_format | No | answer |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It describes the tool as researching external sources (Crunchbase, PitchBook, etc.), implying a read-only operation with no side effects. However, it does not explicitly state read-only behavior, auth requirements, rate limits, or what happens if the company is not found. The description is adequate for a simple research tool but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose in the first sentence, followed by specifics on data sources and a well-structured Args section. While slightly verbose (e.g., listing all sources), every sentence adds value. The length is appropriate for the complexity of the tool.
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 that an output schema exists (mentioned in context), the description does not need to detail return values. It covers the tool's scope (funding history, rounds, valuation, investors), parameter usage, and data sources. Missing elements like prerequisites (e.g., company existence) or limitations are not critical for a research tool. The description is sufficiently complete for an agent to use it effectively.
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 input schema has 0% description coverage, so the description carries full burden for parameter semantics. The Args section explains all 5 parameters: company_name (required), output_format (with explicit options 'answer' and 'structured'), from_date and to_date (date ranges YYYY-MM-DD), and max_results (range 1-50). This adds significant meaning beyond the schema's titles and defaults.
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 retrieves funding and valuation information, specifying the verb 'Get' and the resource 'funding and valuation information about a company'. It lists specific data types (funding history, rounds, valuation, investors) and sources (Crunchbase, PitchBook, etc.), distinguishing it from sibling tools like company_financials and company_overview, which cover broader or different aspects.
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 does not provide any guidance on when to use this tool versus alternatives, such as sibling tools like company_financials or company_overview. It lacks explicit 'when-to-use' or 'when-not-to-use' instructions, leaving the agent to infer context from the tool's name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a company's leadership team.
Identifies CEO, C-suite executives, founders, board members, key hires, and notable departures.
Args: company_name: The name of the company to research output_format: "answer" for natural language with sources, "structured" for JSON include_images: Include executive headshots max_results: Maximum sources to consider (1-50)
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | ||
| company_name | Yes | ||
| output_format | No | answer | |
| include_images | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, required permissions, rate limits, or potential side effects. It only states what it returns.
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 and front-loaded with the purpose. The Args section is structured but not verbose. Every sentence provides value, though it could be slightly more compact.
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 an output schema present, the description covers return format and the types of information retrieved. It lacks details on error handling or empty results, but for a simple query tool this is acceptable.
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 description explains each parameter beyond the schema: company_name is the name of the company, output_format specifies 'answer' or 'structured', include_images adds headshots, and max_results gives a range (1-50). This adds significant meaning over the schema's type and title fields.
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 retrieves a company's leadership team and lists specific roles (CEO, C-suite, founders, etc.), distinguishing it from sibling tools like company_overview or company_funding. The verb 'Get' is generic but sufficient.
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?
No guidance is given on when to use this tool versus alternatives (e.g., research_company). It does not specify prerequisites or context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the market and industry context for a company.
Researches industry classification, market size (TAM/SAM/SOM), industry growth rate, market trends, and regulatory environment.
Args: company_name: The name of the company to research output_format: "answer" for natural language with sources, "structured" for JSON max_results: Maximum sources to consider (1-50)
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | ||
| company_name | Yes | ||
| output_format | No | answer |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, leaving the description as the sole source for behavioral traits. It describes the tool as a research operation (implied read-only) but does not disclose auth needs, rate limits, or side effects. The description is adequate but not detailed.
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, front-loading the main purpose and then listing parameters efficiently. Every sentence adds value, with no unnecessary 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?
The description covers the tool's functionality and inputs well, and an output schema is present. It does not address edge cases like company not found, but overall completeness is high for a research 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 0% schema description coverage, the description fully compensates by explaining each parameter: company_name, output_format (with values 'answer' and 'structured'), and max_results (with range 1-50). This adds significant meaning 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 the tool provides market and industry context for a company, listing specific aspects like industry classification, market size, growth rate, trends, and regulatory environment. This distinguishes it from siblings such as competitive_landscape or company_strategy.
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 implies usage through its purpose, but does not explicitly state when to use this tool versus alternatives or provide conditions for use. No exclusionary guidance is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest news and developments about a company.
Searches news sources, press releases, and publications for recent coverage including product launches, funding, partnerships, and M&A activity.
Args: company_name: The name of the company to research topic: Optional topic filter (e.g., 'funding', 'product launch', 'partnerships') output_format: "answer" for natural language with sources, "structured" for JSON from_date: Start date for news (YYYY-MM-DD format) to_date: End date for news (YYYY-MM-DD format) include_domains: Comma-separated domains to include (e.g., "techcrunch.com,reuters.com") exclude_domains: Comma-separated domains to exclude max_results: Maximum number of news items (1-50)
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | ||
| to_date | No | ||
| from_date | No | ||
| max_results | No | ||
| company_name | Yes | ||
| output_format | No | answer | |
| exclude_domains | No | ||
| include_domains | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It mentions date ranges and output formats but does not cover rate limits, authentication requirements, or what happens if the company is not found. The behavioral aspects are minimally addressed.
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, front-loaded with a clear summary, and uses a structured list for parameters. Every sentence earns its place without 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?
Given 8 parameters and no annotations, the description covers parameter meanings, source types, and output format options. It does not detail the output structure, but an output schema exists to fill that gap. Overall, it provides sufficient context for basic usage.
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 input schema has 0% description coverage, but the description includes a docstring explaining each parameter with examples (e.g., topic filter with example values, date format). This adds significant meaning 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 'the latest news and developments about a company' and lists specific types of coverage (product launches, funding, partnerships). This distinguishes it from sibling tools that focus on other aspects like financials or culture.
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?
No explicit guidance on when to use this tool versus alternatives. With many sibling tools, the description should indicate when company_news is the right choice, but it only describes what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a comprehensive overview of a company.
Researches the company's website, LinkedIn, and press coverage to provide detailed information about what they do, their industry, size, and business model.
Args: company_name: The name of the company to research output_format: "answer" for natural language with sources, "structured" for JSON include_images: Include relevant company images (logos, office, products) max_results: Maximum number of sources to consider (1-50)
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | ||
| company_name | Yes | ||
| output_format | No | answer | |
| include_images | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It states the data sources and output type but omits details on potential side effects, authentication requirements, rate limits, or limitations (e.g., company size or information recency). The description is adequate but not comprehensive.
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, with a clear overview sentence followed by a list of arguments. It is well-structured and front-loaded. However, the argument list could be slightly more compact; the current format is clear but not maximally efficient.
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 presence of an output schema, the description does not need to detail return values. It covers the tool's scope (company overview, sources, content types) and parameters adequately. Minor gaps include lack of mention of error handling or performance expectations, but overall it is sufficiently complete.
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 input schema has 0% description coverage, but the description compensates fully by explaining each parameter: company_name (target company), output_format (with options 'answer' or 'structured'), include_images (binary flag), and max_results (range 1-50). This adds significant value beyond the schema itself.
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 overview of a company.' It specifies the research sources (website, LinkedIn, press coverage) and the information provided (industry, size, business model). The name and description effectively distinguish it from sibling tools like company_financials or company_leadership, which focus on specific aspects.
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 implies when to use this tool (for a broad overview) but does not explicitly state when not to use it or suggest alternatives from the sibling list. It lacks guidance on conditions that would favor a more specific tool, such as financial or leadership details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find partnerships, integrations, and strategic alliances for a company.
Researches partner pages, integration marketplaces, press releases, and partner programs to map the company's ecosystem.
Args: company_name: The name of the company to research output_format: "answer" for natural language with sources, "structured" for JSON max_results: Maximum sources to consider (1-50)
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | ||
| company_name | Yes | ||
| output_format | No | answer |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses the research sources and scope (mapping ecosystem). As a read tool, it does not hide destructive behavior. The description adds value beyond a simple 'find partnerships' statement.
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 one short paragraph plus a bulleted arg list, front-loading the main purpose. No extraneous information. Could be slightly improved with clearer separation of purpose vs. args, but overall efficient.
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?
An output schema exists, so return values are covered outside the description. The description explains the research approach and output_format parameter. Given moderate complexity and no nested objects, it provides sufficient context for an agent to select and 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?
Schema description coverage is 0%, so description must compensate. However, it merely repeats parameter names and types (e.g., 'company_name: The name of the company to research'). It adds no extra detail about data types, constraints, or format expectations 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 the verb 'Find' and the resource 'partnerships, integrations, and strategic alliances', specifying the sources researched (partner pages, integration marketplaces, press releases, partner programs). This differentiates it from sibling tools like company_clients or competitive_landscape.
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 implies usage context ('to map the company's ecosystem') but does not explicitly state when to use this tool versus alternatives. No 'when not to use' guidance is provided, leaving the agent to infer based on the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a company's products and services.
Researches the company's product pages, pricing, and documentation to provide detailed information about their offerings, pricing models, and use cases.
Args: company_name: The name of the company to research product_name: Optional filter for a specific product output_format: "answer" for natural language with sources, "structured" for JSON max_results: Maximum number of sources to consider (1-50)
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | ||
| company_name | Yes | ||
| product_name | No | ||
| output_format | No | answer |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It indicates the tool performs research (likely read-only) but does not explicitly state it is non-destructive, mention authentication needs, rate limits, or error handling. The disclosure is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose sentence followed by an args list. It is concise but could integrate the parameters into flowing text for better readability. 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 the tool has 4 parameters and an output schema, the description covers the basics but lacks context on data freshness, error handling, or how results are sourced. It is minimally complete for a research tool but could add more usage context.
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 0%, so the description fully compensates. It explains the meaning and allowed values for all four parameters: company_name (required), product_name (optional filter), output_format (two options with descriptions), and max_results (range 1-50). This adds significant 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?
The description clearly states the tool's purpose: 'Get information about a company's products and services.' It elaborates on researching product pages, pricing, and documentation, which is specific enough to distinguish it from sibling tools like company_overview or company_technology.
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 implies when to use this tool (when needing product and service info) but does not explicitly state when not to use it or provide alternatives. No comparison with sibling tools or exclusions are mentioned, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assess risk factors for a company.
Researches competitive risks, regulatory risks, legal exposure, key person dependency, customer concentration, technology risks, and market risks.
Args: company_name: The name of the company to research output_format: "answer" for natural language with sources, "structured" for JSON max_results: Maximum sources to consider (1-50)
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | ||
| company_name | Yes | ||
| output_format | No | answer |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It lists risk categories but lacks disclosure on side effects, authentication needs, rate limits, or data freshness, leaving behavioral traits unclear.
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, front-loaded with purpose, and structured with a clear args list. Every sentence adds value with 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?
The description covers purpose, args, and output format options (answer vs structured). Given an output schema exists, it does not need to detail return values, but mentioning that sources are included would enhance completeness.
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 0%, and the description fully compensates by explaining each parameter: company_name (name), output_format (two options), and max_results (range 1-50, default 15), adding meaning 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 starts with a clear verb and resource ('Assess risk factors for a company') and lists specific risk categories (competitive, regulatory, etc.), distinguishing it from siblings like company_financials or company_culture.
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 implies use when needing risk assessment but does not explicitly state when to avoid using it or mention alternative tools among the many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a company's strategic direction.
Researches growth strategy, expansion plans (geographic, product, vertical), M&A history, acquisition rumors, and IPO signals.
Args: company_name: The name of the company to research output_format: "answer" for natural language with sources, "structured" for JSON max_results: Maximum sources to consider (1-50)
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | ||
| company_name | Yes | ||
| output_format | No | answer |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral traits. It discloses output format options and max_results, but does not explicitly state it is read-only or non-destructive. Still, it is fairly 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?
The description is concise, front-loaded with the main purpose, and efficiently lists parameters. Every sentence adds value without 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?
Given the presence of an output schema, the description adequately covers the research scope and parameter details. It is complete for a research tool among many siblings.
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 0% schema description coverage, the description fully explains each parameter: company_name, output_format (with values), and max_results (with range). This adds significant 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?
The description clearly states the tool retrieves a company's strategic direction, listing specific topics like growth strategy, M&A, and IPO signals. This distinguishes it from other company_* siblings by focusing on strategy.
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 explains what the tool does but provides no guidance on when to use it versus alternatives like company_overview or competitive_landscape. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a company's target market.
Researches the company's ideal customer profile, customer segments, geographic markets, and vertical focus.
Args: company_name: The name of the company to research output_format: "answer" for natural language with sources, "structured" for JSON max_results: Maximum number of sources to consider (1-50)
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | ||
| company_name | Yes | ||
| output_format | No | answer |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 describes what the tool does (researches), but does not disclose any behavioral traits such as side effects, rate limits, or whether it is read-only. For a research tool, this is adequate but not exceptional.
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 well-structured with a concise top line followed by a bulleted Args list. Every sentence adds value without 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?
Given that no annotations exist and an output schema is present, the description covers the essential purpose and parameters. It could optionally mention typical use cases or limitations, but is complete enough for an agent to use correctly.
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 description coverage is 0%, but the description includes an 'Args' section that explains each parameter: company_name (the company to research), output_format ('answer' vs 'structured'), and max_results (max sources, 1-50). This adds significant meaning beyond the schema's titles and defaults.
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?
Description clearly states it retrieves information about a company's target market, listing specific aspects like ideal customer profile, segments, geographies, and verticals. This distinguishes it from sibling tools such as company_market (broader) and research_company (general).
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?
While there is no explicit 'when to use' statement, the description outlines the tool's function and the sibling list provides context. Users can infer usage for researching target market details, but no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Research a company's technology stack, patents, and technical approach.
Analyzes engineering blogs, job postings, tech detection tools, patents, and open source contributions to understand technical capabilities.
Args: company_name: The name of the company to research output_format: "answer" for natural language with sources, "structured" for JSON max_results: Maximum sources to consider (1-50)
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | ||
| company_name | Yes | ||
| output_format | No | answer |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions analyzing multiple source types and output formats but does not disclose potential limitations, rate limits, authentication needs, or whether results are cached.
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, front-loaded with the core purpose, and well-structured with a clear Args breakdown. Every sentence serves a purpose without 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?
Given the presence of an output schema and the moderate complexity, the description sufficiently covers the tool's scope and arguments. It could add more behavioral details (e.g., how sources are prioritized) but is mostly complete.
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 description coverage is 0%, but the description's Args section adds value by explaining the purpose and defaults of company_name, output_format, and max_results beyond the schema's basic property definitions.
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 the tool researches a company's technology stack, patents, and technical approach, listing specific sources. It clearly distinguishes from sibling tools (e.g., company_overview, company_products) by focusing on technical capabilities.
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 implies when to use (when needing technical research), but does not provide explicit when-not-to-use guidance or comparisons with alternatives among the 17 sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a company's competitive position in their market.
Identifies competitors, market positioning, differentiators, and competitive advantages through research of industry reports, review sites, and company materials.
Args: company_name: The name of the company to research output_format: "answer" for natural language with sources, "structured" for JSON include_images: Include competitor logos and comparison visuals max_results: Maximum sources to consider (1-50)
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | ||
| company_name | Yes | ||
| output_format | No | answer | |
| include_images | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the research sources (industry reports, review sites, company materials) but does not reveal potential limitations like data freshness, scope, or time required.
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 with a clear structure: purpose statement, output list, and parameter list. It avoids unnecessary details but is slightly verbose in listing the output components.
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 presence of an output schema and four parameters, the description provides adequate context. It explains the tool's function and parameters, though it could elaborate on output behavior (e.g., when data is unavailable).
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 description coverage is 0%, so the description must compensate. It lists all four parameters in the Args section with brief explanations, including possible values for output_format and range for max_results, adding meaning beyond the schema titles.
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: 'Analyze a company's competitive position in their market.' It specifies the output components (competitors, positioning, differentiators, advantages) and distinguishes from sibling tools that cover other aspects like business model or culture.
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?
No guidance is provided on when to use this tool versus alternatives. The description lacks explicit context for appropriate usage, such as prerequisites or conditions, and does not mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Comprehensive company research using parallel tool calls.
Use this tool for vague queries like "research [company]" or "tell me about [company]". Calls 3 specialized tools in parallel (overview, funding, competitors) and combines the results into a complete company profile.
This is faster than Claude calling 5-6 tools sequentially for general research.
Args: company_name: The name of the company to research max_results: Maximum number of sources per tool (1-50)
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | ||
| company_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses parallel tool calls (3 in parallel) and combination of results. No annotations provided, but description covers key behaviors. Could mention any rate limits or permissions.
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?
Well-structured: first sentence states purpose, then usage guidance, internal method, and argument descriptions. No wasted words, appropriate length.
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 output schema exists, description adequately explains that tool combines results into a complete profile. Sibling tools list provides context for alternatives.
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?
Adds meaning to both parameters: company_name is 'the name of the company' and max_results is 'maximum number of sources per tool (1-50)'. Schema has 0% coverage, so description compensates.
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: comprehensive company research by calling specialized tools in parallel. It distinguishes from sibling tools by being a meta-tool for vague queries.
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 ('vague queries like research [company]'). Does not explicitly state when not to use, but context implies using siblings for specific aspects.
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.4.0company_business_modelcompany_clientscompany_culturecompany_esgcompany_financialscompany_fundingcompany_leadershipcompany_marketcompany_newscompany_overviewcompany_partnershipscompany_productscompany_riskscompany_strategycompany_target_marketcompany_technologycompetitive_landscaperesearch_companyScored across 18 tools
Each tool targets a distinct aspect of company research (e.g., business model, culture, ESG, financials, funding, leadership, etc.), with no overlapping purposes. The descriptions clearly differentiate the scope of each tool.
Most tools follow the company_<noun> pattern (e.g., company_overview, company_financials), but 'competitive_landscape' and 'research_company' deviate slightly, breaking the full consistency. Still, names are descriptive and easy to understand.
18 tools is slightly above the typical well-scoped range (3-15), but the number is justified by the comprehensive coverage of company research domains. No tool feels redundant.
The tool set covers most key aspects of company research (financials, funding, leadership, products, market, competitors, etc.). A minor gap might be historical background, but the 'research_company' tool combines multiple tools to provide a broad overview.
11 company intelligence tools — financials, tech stack, competitors, patents, jobs, news. Free.
Global B2B intelligence for AI agents: 35M+ companies, 1.6M sanctions, KYB pack. 78 tools.
The Google for AI agents — company intel, competitor tracking, market research via MCP. JSON output
AI research on companies and industries — one MCP tool per research domain.
