Tracxn MCP Server
Enables configuration of the server through environment variables, particularly for storing and accessing the Tracxn API key securely.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Tracxn MCP Serverget details about Stripe's latest funding round"
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.
Tracxn MCP Server
A Model Context Protocol (MCP) server that wraps the Tracxn REST API, providing a standardized interface for LLMs to interact with Tracxn data.
Prerequisites
Node.js 20 or higher
Tracxn API key
Related MCP server: Beyond MCP Server
Setup
Clone the repository:
git clone <repository-url> cd tracxn-mcpInstall dependencies:
npm installCreate a
.envfile:cp .env.example .envAdd your Tracxn API key to the
.envfile:TRACXN_API_KEY=your_api_key_here
Running the Server
Development mode:
npm run devProduction mode:
npm run build
npm startThe server will start on port 3000 by default. You can change this by setting the PORT environment variable.
Available Tools
get_company: Fetch detailed information about a companyMore tools will be added based on Tracxn API endpoints
Resources
tracxn_raw: Access raw JSON data from any Tracxn API endpoint (read-only)
Error Handling
The server includes:
Rate limiting with exponential backoff and jitter
Error classification for common HTTP status codes
Proper error propagation to clients
License
MIT
Available Tools
1 toolget_companyB
Fetch detailed information about a company from Tracxn
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | Yes | The unique identifier of the company |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| name | Yes | |
| description | No |
TDQS
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 but only mentions fetching information without details on permissions, rate limits, error handling, or response format. It lacks critical context for safe and effective use, though it doesn't contradict any annotations.
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 a single, efficient sentence that directly states the tool's purpose without any unnecessary words or structural fluff. It is appropriately sized and front-loaded, making it easy to parse quickly.
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 siblings, output schema provided) and lack of annotations, the description is minimally complete but lacks depth. It covers the basic purpose but misses behavioral details that would help an agent use it effectively in varied contexts.
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 description coverage is 100%, with the single parameter 'companyId' well-documented in the schema. The description adds no additional meaning about parameters beyond what the schema provides, so it meets the baseline for adequate but unenhanced parameter semantics.
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 action ('Fetch detailed information') and resource ('about a company from Tracxn'), making the purpose immediately understandable. However, since there are no sibling tools mentioned, it cannot demonstrate differentiation from alternatives, which prevents a perfect score.
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 no guidance on when to use this tool versus alternatives, prerequisites, or contextual constraints. It simply states what the tool does without any usage instructions or exclusions, leaving the agent with minimal operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- First observed
get_company
TDQS
Scored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools, as there are no other tools to compare it to. The tool's purpose is clearly defined and distinct by default.
The single tool follows a consistent verb_noun pattern (get_company), which is straightforward and predictable. Since there are no other tools, there is no inconsistency to evaluate.
A single tool is too few for a server named 'Tracxn MCP Server', which implies a broader scope related to company data. This minimal set feels thin and inadequate for typical agent workflows, limiting functionality to just fetching company details without supporting operations like search, update, or listing.
The tool surface is severely incomplete for a company data domain; it only provides a get operation for companies, with no support for searching, listing, creating, updating, or deleting data. This leaves significant gaps that will cause agent failures in handling common tasks.
Maintenance
Related MCP Connectors
A Model Context Protocol server for Wix AI tools
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
A Model Context Protocol server exposing real-time and historical Colombo Stock Exchange (CSE) data to AI agents and LLM applications. Provides quotes and OHLCV price history, full financial statements (income, balance sheet, cash flow), pre-computed technicals (moving averages, RS ratings, volume signals), macroeconomic indicators, corporate actions, and rule-based screening across CSE stocks and sector indices, everything needed to build CSE-aware trading assistants, research tools, and market-analysis agents. This is the official MCP server of www.ceyloncharts.com
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
Related MCP Servers
- AlicenseBqualityDmaintenanceA Model Context Protocol server that provides LLMs with access to Valyu's knowledge retrieval and feedback APIs for searching proprietary/web sources and submitting transaction feedback.2MIT
- AlicenseCqualityDmaintenanceAn extensible Model Context Protocol server that provides standardized access to social platform data (currently Farcaster) and onchain data for LLMs.1013MIT

ZenML MCP Serverofficial
AlicenseBqualityBmaintenanceA server implementing Model Context Protocol that enables LLMs to interact with the ZenML platform, providing access to pipeline data, stack information, and the ability to trigger new pipeline runs.4549MIT- AlicenseBqualityBmaintenanceA Model Context Protocol (MCP) server that provides access to Crunchbase data for AI assistants. This server allows AI assistants to search for companies, get company details, funding information, acquisitions, and people data from Crunchbase.516MIT