Click on "Install 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., "@Vala-Fi MCP Server Who are Apple's main suppliers?"
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.
A Bloomberg Terminal you can talk to. Query company relationships — suppliers, customers, competitors, supply chain paths — directly from Claude, Cursor, or any MCP-compatible AI assistant.
Every relationship is extracted from SEC 10-K filings. Every edge has a citation. No black boxes.
Bloomberg Terminal costs $24,000/year. FactSet starts at $12,000. PitchBook won't even show you pricing without a sales call.
Vala-Fi gives you the same company relationship data for free.
We extract supplier, customer, and competitor relationships from SEC 10-K annual filings using AI — the same source of truth that institutional investors rely on. The difference: you get it as a structured API with graph traversal, not a 200-page PDF.
5,200+ companies. 8,000+ relationships. 11 sectors. Free during beta.
Related MCP server: DataLayer MCP
Sign up at valafi.dev/signup — takes 10 seconds, no credit card.
No packages to install. Just paste the config and go.
Claude Desktop — add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):
{
"mcpServers": {
"vala-fi": {
"url": "https://mcp.valafi.dev/mcp",
"headers": {
"X-API-Key": "vfi_your_key_here"
}
}
}
}Cursor — add to .cursor/mcp.json:
{
"mcpServers": {
"vala-fi": {
"url": "https://mcp.valafi.dev/mcp",
"headers": {
"X-API-Key": "vfi_your_key_here"
}
}
}
}Windsurf / Claude Code — same config format as above.
If you prefer running the server locally (required for Claude Desktop):
{
"mcpServers": {
"vala-fi": {
"command": "/full/path/to/uvx",
"args": ["vala-fi-mcp"],
"env": {
"VALAFI_API_KEY": "vfi_your_key_here"
}
}
}
}Find your uvx path by running which uvx in your terminal. Requires Python 3.10+ and uv.
That's it. Your AI assistant now has access to a financial knowledge graph.
Tool | Description |
| Company name, sector, industry, exchange |
| Upstream/downstream relationships (1-3 hops) |
| All known customers with SEC citations |
| All known competitors with SEC citations |
| Shortest path between two companies |
| Supply chain concentration risk analysis |
| Full sector relationship subgraph (paid tier) |
Pre-built prompt templates you can invoke directly:
Prompt | Description |
| Deep-dive a company's suppliers, customers, competitors, and concentration risk |
| Compare two companies — shared suppliers, paths, competitive overlap |
| Cross-portfolio supply chain risk assessment (pass comma-separated tickers) |
| Structured due diligence memo from SEC filing data |
Resource URI | Description |
| List of all 11 sectors covered in the knowledge graph |
| API overview, endpoint URL, and free tier limits |
Ask your AI assistant questions like:
"Who are Apple's top suppliers?"
"Find the connection between Tesla and NVIDIA"
"What companies depend on TSMC as a sole supplier?"
"Show me all competitors of Microsoft mentioned in SEC filings"
"What's the supply chain risk for my portfolio: AAPL, MSFT, GOOGL?"
Every answer comes with the SEC filing citation so you can verify it yourself.
You're building a stock analysis tool and need to understand company relationships without paying for a Bloomberg Terminal. Vala-Fi gives you structured supply chain data through a simple API.
You're building an autonomous research agent that needs to answer questions like "What happens to Apple if TSMC has a production issue?" Plug in Vala-Fi as an MCP tool and your agent can traverse the financial graph.
You're modeling supply chain risk or building factor models that incorporate inter-company dependencies. Query the graph programmatically and get SEC-cited evidence for every relationship.
You're evaluating an acquisition target and need to quickly map their supplier/customer network. One API call gives you the full picture with citations.
You're writing analysis and need to verify company relationships. Instead of reading 10-K filings manually, query the graph and get the exact excerpt.
Limit | Value |
Requests per day | 50 |
Unique tickers per day | 10 |
Results per query | 5 |
Max hop depth | 2 |
Strength scores | Included |
SEC citations | All results |
Sector graph | Paid only |
Need more? Contact us.
You: Who are NVIDIA's main suppliers according to SEC filings?
Claude: Based on NVIDIA's SEC 10-K filings, here are their key suppliers:
1. **TSMC** (TSM) - Primary foundry partner manufacturing NVIDIA's GPUs
"Taiwan Semiconductor Manufacturing Company Limited manufactures
our GPUs and Tegra processors..." — NVIDIA 10-K
2. **Samsung Electronics** - Secondary foundry for certain chip production
"Samsung manufactures different different different different..." — NVIDIA 10-K
3. **Amkor Technology** (AMKR) - Packaging and testing services
"We use third-party foundries, including TSMC and Samsung,
and packaging and test providers such as Amkor..." — NVIDIA 10-KDon't need an AI assistant? Use the REST API directly:
# Get Apple's suppliers
curl -H "X-API-Key: vfi_your_key" \
https://api.valafi.dev/v1/company/AAPL/supply-chain
# Find path between Tesla and NVIDIA
curl -H "X-API-Key: vfi_your_key" \
https://api.valafi.dev/v1/path/TSLA/NVDA
# Get supply chain risk for a company
curl -H "X-API-Key: vfi_your_key" \
https://api.valafi.dev/v1/exposure/AAPLFull API documentation: valafi.dev/docs
All relationship data is extracted from SEC 10-K annual filings using AI. We do not scrape news, social media, or third-party databases.
Source: SEC EDGAR
Coverage: 5,200+ public companies across 11 GICS sectors
Update frequency: As new 10-K filings are published (primarily Q1 and Q3)
Relationship types: supplier, customer, competitor, partner, and more
Website: valafi.dev
API Docs: valafi.dev/docs
Get API Key: valafi.dev/signup
Pricing: valafi.dev/pricing
MIT — use it however you want.
Find the shortest path between two companies in the knowledge graph.
Discovers how two companies are connected through supplier, customer, and competitor relationships. Great for finding hidden connections.
Example: find_path("AAPL", "NVDA") -> Apple -> TSMC -> NVIDIA (connected through shared semiconductor supplier)
| Name | Required | Description | Default |
|---|---|---|---|
| ticker_a | Yes | ||
| ticker_b | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool uses supplier, customer, and competitor relationships and returns the shortest path via an example. However, it does not specify what happens if no path exists, if multiple paths exist, or performance implications. 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: two sentences and an example. It is front-loaded with the main purpose, and the example adds concrete understanding without extraneous content. Every sentence is useful and earn its place.
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 no output schema, moderate complexity, and simple parameters, the description covers the core functionality and relationships. However, it lacks details on output format, error handling, and assumptions (e.g., case sensitivity). It is adequate for a basic agent but incomplete for reliable autonomous invocation.
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 does not formally define ticker_a and ticker_b beyond the example showing stock tickers. The example provides partial meaning, but lacks explicit format or constraint details. The description adds some value for interpretation but insufficiently compensates for the missing schema 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 the tool finds the shortest path between two companies in a knowledge graph using supplier, customer, and competitor relationships. This distinguishes it from sibling tools like get_competitors (direct competitors) or get_supply_chain (full chain), making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context ('Great for finding hidden connections') but does not explicitly state when to use this tool versus alternatives or when not to use it. The example illustrates a use case, aiding inference, but lacks explicit exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get company profile by ticker symbol.
Returns basic company information including name, sector, industry, country, and exchange. Use this to look up any company in the graph.
Example: get_company_profile("AAPL") -> Apple Inc., Technology, Consumer Electronics
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | 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 clearly describes the tool as a read operation returning basic information, which is adequate for a simple lookup. However, it does not disclose any potential errors, prerequisites, or side effects, but given the straightforward nature, a score of 3 is appropriate.
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 two sentences plus an example, no wasted words. It front-loads the action and key information, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the purpose, input format, return fields, and usage context. It provides an example, which is complete for a lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter `ticker` has 0% schema description coverage, but the description adds essential meaning by explaining it is a ticker symbol and providing an example ('AAPL'). This fully compensates for the missing schema detail, making the parameter semantics clear.
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 uses a specific verb ('Get') and resource ('company profile') and specifies the input ('by ticker symbol'). It lists the returned fields (name, sector, industry, country, exchange) and provides an example, clearly distinguishing it from sibling tools like get_competitors or get_supply_chain.
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 states 'Use this to look up any company in the graph,' giving clear context for when to use the tool. It does not explicitly list when not to use it or name alternatives, but the sibling tools cover different functionalities, making the usage guidance clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all known competitors of a company.
Competitors are identified from SEC 10-K filings where companies explicitly name their competitive landscape.
Example: get_competitors("AAPL") -> Microsoft, Samsung, Google...
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It states the source and example output but lacks details on error handling, input validation, authorization needs, or limitations (e.g., only US companies from SEC filings). The example helps, but more context is needed for thorough transparency.
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 (3 sentences) and front-loaded with the core purpose. Every sentence adds value: purpose, source, and example. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is mostly complete. It explains the source and provides an example output format. However, it could mention potential empty results or ticker requirements for full 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%, so the description must explain the 'ticker' parameter. The example uses 'AAPL' to imply it's a stock ticker, but the description does not explicitly define 'ticker' or its valid format. This provides marginal added 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 all known competitors of a company.' It specifies the data source (SEC 10-K filings) and provides a concrete example (AAPL -> Microsoft, Samsung, Google). This differentiates it from sibling tools like get_customers or get_supply_chain.
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 when to use the tool (to retrieve competitors) but does not explicitly state when not to use it or how it compares to alternatives. While the sibling list exists, no direct comparison or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all known customers of a company.
Returns companies that list the queried company as a supplier in their SEC 10-K filings. Each relationship includes citation evidence.
Example: get_customers("TSM") -> Apple, NVIDIA, AMD, Qualcomm...
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that results come from SEC 10-K filings and include citation evidence, which is good. However, it does not mention potential limitations like data recency, pagination, or read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences plus an example, all front-loaded. Every sentence adds value: purpose, source, evidence, example. No unnecessary words.
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 simplicity (one parameter, no output schema, no annotations), the description is largely complete. It explains the output (customers with citation evidence) and the data source. Could mention limitations like only covering SEC filings, but overall sufficient.
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 schema coverage is 0%, meaning the description does not explicitly describe the parameter 'ticker'. The example shows usage with 'TSM', implying it is a stock ticker, but no formal definition is given. The description should compensate by explicitly stating the parameter meaning.
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 states 'Get all known customers of a company' which is a specific verb+resource. It elaborates on the source (SEC 10-K filings) and provides an example. This clearly distinguishes it from sibling tools like get_competitors and get_supply_chain.
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 when-to-use or when-not-to-use guidance is given. However, the purpose is clear enough that an agent can infer when to use it for customer relationships. Alternatives like get_competitors are not mentioned, but the tool name provides distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get supply chain exposure and concentration risk analysis.
Identifies shared suppliers/customers across peer companies and flags single-source dependencies. Returns an exposure score.
Example: get_exposure("AAPL") -> Shows TSMC as a high-risk sole supplier, shared suppliers with peers
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It describes the tool's functionality (identifies dependencies, returns score) but does not disclose behavioral traits such as read-only nature, authorization requirements, or rate limits. The example hints at a read operation, but explicitness is lacking.
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 two sentences plus an example, with no redundancy. It front-loads the purpose, then provides concrete illustration. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema, no nested objects), the description provides adequate context. The example clarifies the output format. However, it could mention any limitations (e.g., only US stocks) or default behavior.
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 schema has 0% description coverage for the 'ticker' parameter, but the description adds meaning by contextualizing it as a company ticker for supply chain analysis. The example 'AAPL' reinforces this. While not exhaustive, it adds significant value beyond the raw 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 'supply chain exposure and concentration risk analysis', identifies shared suppliers/customers, flags single-source dependencies, and returns an exposure score. The example with ticker 'AAPL' further clarifies the scope, effectively distinguishing it from sibling tools like get_supply_chain or get_competitors.
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 supply chain risk analysis is needed, but does not explicitly state when to use this tool versus alternatives (e.g., get_supply_chain for raw lists, get_competitors for competition). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full relationship subgraph for an entire sector.
Returns all companies and edges within the specified sector. Note: This endpoint requires a paid tier.
Args: sector: Sector name (e.g. "Technology", "Healthcare", "Energy", "Financial Services", "Consumer Cyclical", "Industrials", "Communication Services", "Consumer Defensive", "Basic Materials", "Real Estate", "Utilities") relationship_types: Optional comma-separated filter (e.g. "supplier,customer")
Example: get_sector_graph("Technology", relationship_types="supplier")
| Name | Required | Description | Default |
|---|---|---|---|
| sector | Yes | ||
| relationship_types | No |
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 the paid tier requirement and that it returns all companies and edges, but lacks details on rate limits, authentication, or potential side effects. As a read-only operation, the disclosure 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 summary, a critical note, structured parameter list, and an example. Every sentence adds value, and the layout is easy to scan.
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 two parameters and no output schema, the description covers purpose, parameters, and a key limitation (paid tier). It lacks details on response format or error handling, but for this tool's complexity, the provided information is sufficient 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?
Schema description coverage is 0%, but the description includes an Args section with example values for sector and clarifies that relationship_types is an optional comma-separated filter. This adds significant meaning beyond the schema, which only provides parameter names 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 retrieves the full relationship subgraph for a sector, using 'Get' as the verb and specifying the resource as 'full relationship subgraph' for a sector. It distinguishes from sibling tools that focus on individual companies (get_company_profile, get_supply_chain) or path finding (find_path).
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 notes a prerequisite ('requires a paid tier') and provides an example usage. While it doesn't explicitly state when to use this tool vs alternatives, the context ('entire sector') implies it's for sector-level analysis, and sibling tools are clearly for different scopes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the supply chain for a company.
Traverses the knowledge graph to find suppliers, customers, or both. Each relationship includes SEC 10-K citation evidence.
Args: ticker: Stock ticker (e.g. "AAPL", "TSLA") hops: Depth of traversal (1 = direct relationships, 2 = second-degree). Free tier: max 2. direction: "upstream" (suppliers), "downstream" (customers), or "both"
Example: get_supply_chain("AAPL", hops=2, direction="both") -> Shows Apple's suppliers, their suppliers, and Apple's customers
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| hops | No | ||
| direction | No | upstream |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses traversal behavior, citation evidence, and free tier limitations. No contradictions.
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 structured with sections, but slightly verbose. It includes example and argument details, all relevant.
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 3 params, no output schema, and no annotations, the description covers everything: what it does, parameters, example, return evidence, and constraints.
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 fully explains each parameter: ticker, hops, direction, including defaults, example, and constraints.
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 purpose: 'Get the supply chain for a company' with specific verb and resource. It distinguishes from siblings like get_customers by covering both directions.
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 supply chain traversal) and gives an example, but does not explicitly state when not to use it or compare with alternatives.
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. Dates show when Glama detected each change.
v0.1.3find_pathget_company_profileget_competitorsget_customersget_exposureget_sector_graphget_supply_chainScored across 7 tools
Each tool has a clearly distinct purpose: profile lookup, path discovery, competitor/customer lists, supply chain traversal, sector subgraph, and exposure analysis. No overlap or ambiguity.
All tools follow a consistent verb_noun pattern in snake_case (e.g., get_company_profile, find_path). The naming is predictable and clear.
Seven tools is well-scoped for a knowledge graph API, covering essential queries without being overwhelming. Each tool earns its place.
The tool set covers all typical query needs for a company relationship graph: profile, competitors, customers, supply chain, path finding, sector view, and risk analysis. No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The financial MCP for AI agents - 90+ financial tables, SEC filings, signals, alt-data.
Private company data & real-time news signals for AI agents.
Company and market intelligence, news, enrichment, and agentic workflows for dealmakers.
Evidence-backed capital-change intelligence and sourced financial data for AI agents
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/academicnair009/vala-fi-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
