Linkup Company Research MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.4.0
Disambiguation5/5
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.
Naming Consistency4/5
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.
Tool Count4/5
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.
Completeness4/5
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.
Average 3.9/5 across 18 of 18 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness3/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Linkup-MCP-Company-Research MCP server](https://glama.ai/mcp/servers/shauryajain21/Linkup-MCP-Company-Research/badges/card.svg)](https://glama.ai/mcp/servers/shauryajain21/Linkup-MCP-Company-Research)

Score Badge

Copy to your README.md:

[![Linkup-MCP-Company-Research MCP server](https://glama.ai/mcp/servers/shauryajain21/Linkup-MCP-Company-Research/badges/score.svg)](https://glama.ai/mcp/servers/shauryajain21/Linkup-MCP-Company-Research)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/shauryajain21/Linkup-MCP-Company-Research'

If you have feedback or need assistance with the MCP directory API, please join our Discord server