Wealthnow

Private markets tools

private_markets_tools

Read-onlyIdempotent

Private companies, deals, investors, funds, limited partners, valuations and relations. Use it for private companies' funding rounds, investors, funds and valuations. Pick one of its 28 operations in operation and pass its arguments in arguments.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "operation": "<operation>"
    },
    "name": "private_markets_tools"
  }
}

Input Schema

Name	Required	Description	Default
`arguments`	No	The operation's own arguments, by the names its line gives. search_tools returns any operation's full inputSchema.
`operation`	Yes	The operation to run. One line each: name(its arguments, * = required): what it does. private_markets_aggregates(by, limit, min_n): Private-market landscape aggregates: company counts, total and median capital raised, median valuation, median employees private_markets_companies(sector, industry_group, country, region, financing_status, business_status, +17 more): SCREEN private companies by sector, geography, financing/business status, size (total raised/valuation/employees, $MILLIONS), founding year private_markets_company(company_id): FULL private-company profile by company_id: financials (revenue/EBITDA/EBIT/net income/EV/net debt), complete financing history (round size/valuation/date/type)... private_markets_company_comparables(company_id, limit, detail, fields): Private peer set for one company: currently-private operating companies in the same industry group (sector when it has none) and a similar size band... private_markets_company_deals(company_id, limit): Funding-round and M&A deal history for a private company (deal size, type, VC round, pre/post-money valuation), newest first private_markets_company_dossier(company_id, deals, peers, investors, blocks, fields): EVERYTHING on a private company in ONE call private_markets_company_investors(company_id, limit, detail, offset): Investor roster for a private company, resolved through the deal-investor relation; detail=full adds every investor column (AUM, dry powder, activity) private_markets_company_page(company_id, tab, deals, team): The private-company DETAIL PAGE in ONE call, render-ready private_markets_company_realtime(company_id): LIVE real-time overlay for a private company: the fast-moving complement to the (weekly, possibly STALE) private-markets profile... private_markets_company_relations(company_id, relation, limit): Traverse a company's private-market graph one edge per call (relation=) private_markets_company_syndicate(company_id, limit): PER-ROUND investor syndicate: who was IN each round, who LED it, and how big the check was private_markets_company_valuation(company_id): A private valuation mark for a company: estimate, confidence band... private_markets_deal(deal_id): Single deal / financing round by deal_id: deal size, type, VC round, pre/post-money valuation, and a synopsis private_markets_deal_relations(deal_id, relation, limit): Traverse a deal's graph one edge per call (relation=): investors, tranches, debt lenders, sellers, service providers, bonds, loans, distribution beneficiaries private_markets_fund(fund_id): Fund profile + performance: vintage, size, category, status, and returns (IRR/DPI/TVPI/RVPI/NAV/quartile) when loaded private_markets_fund_relations(fund_id, relation, limit): Traverse a fund's graph one edge per call (relation=) private_markets_investor(investor_id): Investor profile for one VC/PE/family office by investor_id: type, AUM, dry powder, year founded, investment focus, and median valuation/round private_markets_investor_relations(investor_id, relation, limit): Traverse an investor's graph one edge per call (relation=) private_markets_limited_partner(lp_id): Limited-partner profile by lp_id: LP type, AUM, total/active commitments, allocation to alternatives, and openness to first-time funds private_markets_limited_partner_relations(lp_id, relation, limit): Traverse an LP's graph one edge per call (relation=): fund commitments, board, mandates, news, service providers private_markets_news(limit, sort, category, sector, company_id, q, +1 more): News about PRIVATE companies (venture-backed, unbacked or in IPO registration) from the private-markets news archive private_markets_person(person_id): Person profile (founder/exec/board member) by person_id: role, board seats, affiliated deals/funds, education, and professional-profile link private_markets_person_relations(person_id, relation, limit): Traverse a person's graph one edge per call (relation=): career positions, board seats, education, affiliated deals/funds, advisory roles private_markets_relations(): Catalogue of every queryable relation per private-markets entity type: the map of the private-capital graph private_markets_search(q, type, limit, detail, fields): Search PRIVATE companies / investors (VC/PE) / funds / people / limited partners by name (prefix, case-insensitive), ticker, or CIK private_markets_search_suggest(q, limit): INSTANT (sub-100ms) private-company typeahead: prominence-ranked with the SAME ranking as search, so the famous company is never truncated private_markets_service_provider(sp_id): Advisory-firm profile by sp_id (the law firm, investment bank, auditor or consultancy behind private-market deals) private_markets_service_provider_relations(sp_id, relation*, limit): Reverse adviser index for one service provider: every deal, company, investor, fund or LP the firm has advised (relation= picks the edge, limit default 50)

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety and idempotency profile is fully covered without the description. The description adds no behavioral context of its own (no freshness/staleness note, latency, or result shape) even though the operation enum carries such notes, so this is the baseline 3 for a description that neither contradicts nor enriches the annotations.

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?

Three short sentences, front-loaded with the domain and followed by the dispatch mechanics — nothing extraneous. The first sentence (a bare noun list) and the second ("use it for...") partially repeat the same domain terms, which is the only wasted space.

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?

For a 28-operation dispatcher with no output schema, the description states the domain and the two-argument dispatch pattern, while the enum supplies per-operation semantics and the annotations supply the safety profile. It omits any return/pagination guidance and any pointer to discovering operation schemas (which appears in the schema, not the description), leaving a small gap.

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?

Schema description coverage is 100% and the operation enum documents every one of the 28 operations with its own arguments and behavior, so the description has nothing to compensate for. Its line about passing arguments by name only restates what the schema's "arguments" property already says, so the baseline 3 is appropriate.

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 names the domain (private companies, deals, investors, funds, LPs, valuations, relations) and frames the tool as a dispatcher over 28 operations, which is a clear statement of what it is. It does not differentiate itself from the sibling tools that expose overlapping operations (private_markets_search, private_markets_company_deals, private_markets_company_page), so sibling differentiation is absent.

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?

"Use it for private companies' funding rounds, investors, funds and valuations" gives a clear usage context, and "Pick one of its 28 operations in operation and pass its arguments in arguments" states the invocation contract. No exclusions or alternative routing are provided, and it never explains when to prefer it over the unrelated private_markets_* siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Wealthnow tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.