Paid Business Data MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
The free tools (company_overview, market_trend) and paid tools (enriched_search, competitive_analysis, financial_report) are reasonably distinct in purpose. However, enriched_search and competitive_analysis could overlap since enriched_search includes competitive analysis, potentially causing confusion about which to select for competitive needs.
Naming Consistency4/5
Tool names follow a roughly consistent noun-based pattern (company_overview, market_trend, financial_report) with two verb-style names (enriched_search, competitive_analysis) mixed in. The mixed noun/verb convention is a minor deviation but names remain readable and predictable.
Tool Count5/5
Five tools is well-scoped for a business data server. The split between free and paid tiers is clear and each tool serves a distinct purpose without bloating the surface.
Completeness3/5
The server covers overview, market trends, enriched search, competitive analysis, and financial reporting. However, gaps exist such as no tool for targeted financial data lookup (like a specific financial statement query) or industry-specific company comparisons beyond the paid search.
Average 2.7/5 across 5 of 5 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. The word 'free' hints at cost or access characteristics, but there's no mention of data freshness, source, response format, or limitations. For a tool describing what it returns, it doesn't disclose what the summary contains or how comprehensive it is.
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?
One clean, front-loaded sentence with zero waste. It efficiently conveys the core purpose, though it errs on the side of under-specification rather than genuine conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no annotations, no output schema, and 0% schema coverage, the description is too thin. It doesn't explain what the summary covers, the format of results, or how to formulate the sector parameter correctly. A well-functioning tool with one parameter should be able to fully document its behavior in a few sentences, and this falls short.
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%, meaning the description must compensate for the undocumented 'sector' parameter. The description says 'for any sector' but doesn't clarify the expected format (company name, industry name, ticker symbol), whether free-form text is acceptable, or what constitutes a valid sector input. This is a significant gap given zero schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific language ('Get a free summary of current market trends for any sector') with a verb and resource, clearly indicating it retrieves trend data for sectors. However, it doesn't meaningfully differentiate from siblings like enriched_search or competitive_analysis, which could also surface market information.
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. The 'free' qualifier hints at a distinction from paid tools, but this is not explicit. There's no mention of when the agent should prefer market_trend over enriched_search or competitive_analysis.
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 of behavioral disclosure. It discloses the '$0.10' paid cost which is useful transparency, and reveals the returned data includes competitive analysis and financial data. However, it doesn't disclose rate limits, data freshness, whether results are real-time or cached, or the response format. For a paid tool, more behavioral transparency would be expected.
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?
The description is a single concise sentence that front-loads the paid cost indicator and core purpose. It's efficient but arguably too terse - it captures the essence without wasting words, but leaves out valuable usage guidance that could fit in the same space. The paid tag at the start is informative placement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a paid tool with zero schema coverage, no output schema, and overlapping sibling tools, the description is incomplete. It doesn't explain what 'enriched' means practically, how results differ from running the sibling tools separately, whether the $0.10 is per-call or per-result, or the shape of returned data. For a paid multi-faceted search tool, this needs more context.
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%, and the description adds minimal parameter context. It implies 'query' is a business search term and 'max_results' limits output count, but doesn't explicitly explain either parameter's format, constraints, or semantics. The description tags '[PAID $0.10]' suggesting the cost likely scales with max_results but doesn't state this. The description should compensate for zero schema coverage but barely does.
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 states it performs 'deep enriched business search' with 'competitive analysis and financial data' - clear verb (search) and resource (businesses). It distinguishes itself from siblings by combining competitive analysis and financial data in a single search. However, it doesn't explicitly name which sibling tools it differentiates from or how 'enriched' differs from regular search.
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 gives no guidance on when to use this tool vs the sibling tools (company_overview, market_trend, competitive_analysis, financial_report). It implies a one-stop comprehensive search that combines competitive and financial data, but there are no explicit exclusions or alternative recommendations. Given the sibling tools clearly overlap in competitive/financial domains, this is a significant gap.
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 provided, the description carries the full burden of behavioral disclosure. It mentions a cost of $0.25 (useful) but does not disclose latency, data freshness, coverage limitations, whether both parameters are required, or what the response structure looks like. For a paid tool, the behavioral profile is notably under-specified.
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 a single sentence, tightly packed with content. It's efficiently worded and front-loads the tool's purpose. The [PAID] cost marker is a useful lead element. Minimal waste, though bundled concepts could arguably be expanded slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a moderately complex analytical tool with cost implications, but no annotations, no output schema, and 0% parameter coverage. For a paid tool, an agent needs to know what the response covers (report? data table?), whether both or just one parameter is needed, and what determines the cost. The description addresses scope but leaves operational behavior and prerequisites unclear.
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 the description must compensate. It does not explain what 'company' expects (name? ticker?) or what 'industry' is used for (scoping, filtering?). The description mentions pricing and market positioning, which loosely relate to the parameters, but adds no format, example, or semantic clarity to the schema.
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 states a specific verb ('competitive landscape analysis') with a resource (the competitor), and enumerates covered dimensions: pricing, strengths, weaknesses, and market positioning. This clearly distinguishes it from siblings like company_overview or financial_report. It doesn't explicitly name a competing alternative, but the scope is specific enough to differentiate.
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 when/when-not guidance is provided. There's no mention of prerequisites, interaction with company_overview or market_trend, or scenarios where this tool should or shouldn't be chosen. The [PAID $0.25] tag hints at cost implications but doesn't clarify when the cost is justified versus free alternatives.
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 for behavioral disclosure. The 'generate' verb implies this is a read/query operation that produces a report, but the description doesn't disclose whether data is cached, whether the report is real-time or snapshot-based, whether fiscal_year is required for a report, or what the pricing implication ($0.15) means for repeated/redundant calls. The cost signal is disclosed but broader behavioral context is missing.
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 a single compact sentence that is front-loaded with the 'Generate' action and includes the cost disclosure upfront. It packs purpose and deliverable content efficiently without redundancy. The '[PAID $0.15]' prefix is additive information. Minor deduction for not leveraging the available space to clarify parameter usage.
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?
For a 2-param tool with no output schema and no annotations, the description provides a reasonable core purpose but leaves operational gaps. It doesn't explain what 'peer comparison' entails, how peers are determined, whether historical fiscal_year inputs change the output, or what happens if fiscal_year is omitted. The absence of an output schema means the description should describe what the returned report contains, but it only lists high-level categories (metrics, ratios, peer comparison). Adequate but not complete.
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 the description must compensate for both parameters. The description mentions 'key metrics, ratios, and peer comparison' which implies content but doesn't clarify the meaning of 'company' and 'fiscal_year' beyond their schema types (string). Notably, it doesn't clarify whether fiscal_year is optional (it's not in required) or what format it should take (e.g., '2023' vs 'FY2023'). The description adds minimal parameter meaning beyond the bare schema.
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 states the verb ('Generate'), resource ('a financial health report'), and content ('key metrics, ratios, and peer comparison'). It distinguishes itself from sibling tools like company_overview and competitive_analysis by specifying the deliverable is a financial health report, though the distinction is somewhat subtle. The '[PAID $0.15]' prefix adds useful cost context not present in structured fields.
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 provides no explicit guidance on when to use this vs. alternatives. Sibling tools like company_overview and competitive_analysis could overlap with 'financial health report' functionality, but the description doesn't clarify when this tool is preferred, or when one of the others should be used instead. No exclusions or prerequisites are stated.
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 the full burden of behavioral disclosure. It mentions the tool is 'free', which is somewhat useful, but doesn't disclose data freshness, coverage limitations, whether the info is based on live data or cached, or what happens with unknown/unlisted companies. For a data-lookup tool with no annotation coverage, more context is needed.
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?
A single sentence efficiently conveys the core purpose and what the tool returns. There's no waste or redundancy. The description is appropriately sized for a simple lookup tool with one parameter.
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?
For a one-parameter lookup tool with no output schema and no annotations, the description is somewhat sparse. It tells the agent what data comes back (industry, size, description) but doesn't address edge cases like unavailable companies or whether results vary by market. Given the tool's simplicity, this is adequate but could be enriched with error-handling or coverage notes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'name' has 0% schema description coverage, but the parameter is simple and self-explanatory given the tool name. The description implies that 'name' refers to a company name but doesn't explicitly state it, nor does it clarify format expectations (e.g., full legal name vs. common name, case sensitivity). For a single scalar parameter, the baseline is modest and the description adds minimal but acceptable value.
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 the verb (get) and resource (company overview) with the scope of what it returns: industry, size, and description. It's specific enough to convey the tool's purpose, though it doesn't explicitly differentiate from sibling tools like enriched_search or competitive_analysis.
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 doesn't mention whether this should be used as a first step before competitive_analysis or financial_report, nor does it explain when a more detailed tool would be preferable. Sibling tools like market_trend or competitive_analysis have overlapping domains but no differentiation is given.
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:

[![paid-business-data-mcp MCP server](https://glama.ai/mcp/servers/luisruiz3012/paid-business-data-mcp/badges/card.svg)](https://glama.ai/mcp/servers/luisruiz3012/paid-business-data-mcp)

Score Badge

Copy to your README.md:

[![paid-business-data-mcp MCP server](https://glama.ai/mcp/servers/luisruiz3012/paid-business-data-mcp/badges/score.svg)](https://glama.ai/mcp/servers/luisruiz3012/paid-business-data-mcp)

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/luisruiz3012/paid-business-data-mcp'

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