← Plugin catalog
Finance
Preqin
Blackrock v3.0.0
Publisher description
From the marketplace listing
Preqin MCP connects AI assistants to Preqin data, enabling users to access and analyze information through natural language. By combining AI with trusted private markets intelligence, users can research topics, answer questions, explore data, and support workflows directly within ChatGPT. Preqin MCP helps bring the power of Preqin into modern AI-driven experiences.
Language: English · Automatically detected from descriptions.
Files & skills
File archives
Plugin packageNo download link
preqin-market-overviewNo download link
Skill instructions
preqin-market-overview38.4 KB
--- name: preqin-market-overview description: Generate a scoped, evidence-based overview of a private-markets or alternative-assets market using Preqin data on funds, managers, investors, deals, benchmarks, secondaries, and current signals. Use for market-level questions about what is happening in a segment, including fundraising, participation, deal activity, performance context, or liquidity. Never use when a named fund, manager, investor, company, asset, or transaction is the primary subject, including profiles, performance reviews, benchmark comparisons, commitment analyses, ownership questions, and peer rankings. Incidental market context does not convert an entity-first request into a market overview. --- # Preqin Market Overview Use this skill when the user asks for a market-level explanation of what is happening in an alternative-assets segment covered by Preqin. Do not use this skill for: - Public-market prices, indices, listed-security performance, or current trading conditions. - Any standalone request whose primary subject is one named fund, manager, investor, company, asset, transaction, consultant, service provider, or contact. - Any standalone fund performance, benchmark, commitment, profile, ownership, or service-provider analysis, even when the necessary MCP tools are available. - Investment recommendations or personalized investment advice. A named entity may be included only as supporting evidence inside a request whose primary deliverable is a wider market, asset-class, strategy, geography, sector, or thematic overview. Adding a broad comparison to an entity-first request does not activate this skill. Market-first describes the analytical deliverable, not necessarily the first tool call. When an eligible market-first request explicitly names an entity, resolve that entity early when its ID, type, or canonical link is needed; then retrieve the wider market evidence and keep the entity subordinate to the market analysis. A requested dimension may exist elsewhere in Preqin even when it is not exposed by the current Preqin MCP. Treat this as an integration boundary, not proof that the information is absent from Preqin. Complete the supported MCP analysis first and describe any continuation path conservatively. ## 1. Resolve the request Identify the following when available: - Asset class and strategy or sub-strategy. - Geography. - Time period. - Named fund, manager, investor, company, or other entity. - Primary focus, such as fundraising, managers, investors, deals, performance, secondaries, or current signals. - Desired depth or user-specified format. A recognizable Preqin-covered market is required. If the asset class or market cannot be resolved, ask one focused question. Otherwise, do not ask for optional details that can be handled with stated defaults. Use these defaults unless the user specifies otherwise: - Geography: global. - Event-data period: trailing 12 months ending on the current date. - Snapshot datasets: latest available records. - Comparison period: the immediately preceding equal-length period, but only when a trend comparison is relevant and supported. - Depth: a concise overview with a small number of evidence-backed themes. State material scope choices and defaults in the answer. ## 2. Use only evidence returned by the current Preqin MCP Keep three evidence layers distinct: 1. **Preqin MCP data:** live records the skill can retrieve and calculate from. 2. **Preqin Pro:** broader or more granular private-markets information that may be available outside the current MCP, subject to asset class, dataset coverage, product access, and entitlement. 3. **Preqin research:** analyst reports and market commentary published by Preqin. Use MCP results as the evidential basis of the overview. Do not present unseen Preqin Pro data or unseen research as though it were retrieved evidence. The current MCP supports these market-overview modules: | Module | Primary tools | Appropriate use | |---|---|---| | Fund supply and fundraising | `preqin_fund_filter_values` -> `preqin_funds` | Fund records, strategies, vintages, statuses, targets, closes, dry powder, and fund AUM fields returned by the MCP. | | Manager landscape | `preqin_fund_manager_filter_values` -> `preqin_fund_managers` | Manager-record counts, asset-class AUM, estimated dry powder, funds raised, and funds-in-market fields. | | Investor demand | `preqin_investor_filter_values` -> `preqin_investors` | Investor-record counts, current allocations, preferences, and recorded next-12-month plans. | | Deal activity | `preqin_deal_filter_values` -> `preqin_entity_deal_history` | Deal or transaction records, dates, status where populated, geography, participants, and disclosed value fields. | | Benchmark context | `preqin_pc_benchmarks_filter_values` -> `preqin_private_capital_benchmarks` | Broad market benchmark medians by supported strategy, region, and vintage. A supporting named-fund call may use `fund_id` without categorical benchmark filters. | | Fund performance in market context | `preqin_search` -> `preqin_fund_performance` | Performance for resolved funds when the user also requests wider market or peer context. | | Secondary liquidity | `preqin_secondaries_filter_values` -> `preqin_secondaries` | Secondary transactions, sellers, buyers, dates, types, and disclosed prices. | | Current market signals | `preqin_news_filter_values` -> `preqin_news` | Recorded investor plans, commitments, secondaries activity, searches, people moves, and other categorized news. | | Named-entity context | `preqin_search` -> `preqin_profile` | Context for a named fund, manager, investor, company, or asset within a market-level answer. | | Company financial context (supporting only) | `preqin_search` -> `preqin_company_financials` | Revenue, growth, operating income, EBITDA, and margin history for a small, defined company cohort when it materially supports a wider sector or market theme. | Entity-scoped relationship, ownership, company-financial, and service-provider lookups may support an eligible market-first answer but must never activate this skill on their own. Use consultant or service-provider universe tools only when the market itself is that ecosystem. Contacts are outside this skill and should be handed off to a dedicated contact workflow. ### Preqin Pro positioning When relevant, use conservative language such as: > Preqin Pro may provide broader or more granular private-markets information than is exposed through the current MCP, subject to dataset coverage and the user's access. Preserve relevant Preqin Pro links returned by the MCP. Name a specific additional data type only when it has been returned by the MCP, verified in a packaged reference, supplied by the user, or retrieved from an authoritative Preqin source. Do not promise specific fields merely because related information exists elsewhere in Preqin. When the user requests a dimension that the current MCP does not return: 1. Continue with the supported market overview when that still addresses the main goal. 2. Identify the missing dimension in plain language. 3. State that the current MCP did not expose it. 4. Mention Preqin Pro only as a possible continuation path, subject to coverage and access. 5. Do not invent or estimate unseen values. ### Preqin research positioning Preqin publishes analyst reports and market commentary across private markets. Mention research as a complementary source when the user would benefit from additional historical, sector, regional, fundraising, performance, or thematic context. Do not name, summarize, or attribute a view to a specific article unless that article has been retrieved or supplied. Do not imply that unseen research supports the conclusions in the current response. ## 3. Select the smallest useful set of modules Do not call every available tool. Choose only the modules that answer the question. For a broad market overview, normally use three or four of: 1. Fund supply and fundraising. 2. Deal activity. 3. Manager landscape. 4. Investor demand or current market signals. 5. Performance or secondaries when relevant and supported. Route focused requests as follows: - **Broad "what is happening" request:** prefer dated deal evidence, ranked or dated fund records, and current investor-plan or news signals when useful. For geographically scoped questions, retrieve recent asset-class news globally and retain only stories whose returned headline or detail explicitly establishes relevance to the requested geography. - **Fundraising:** use funds, managers, and relevant investor-plan or fundraising news. Lead with dated closes, largest targets, strategy mix, or current signals rather than weakly current status totals. - **Deal activity:** use deals and relevant news; add a small number of deal profiles only when they materially improve the explanation. - **Investor demand:** use investors plus recorded next-12-month plans and relevant future-plan or commitment news. Treat these as observed signals, not a complete measure of demand. - **Performance:** use broad benchmark context for market questions. Use named-fund performance only as supporting evidence inside an explicitly requested wider market or peer-market overview. Never activate this skill for a standalone named-fund performance or benchmark question. - **Secondaries:** use secondaries, secondary-fund fundraising, and secondary-related news where supported. - **Market-first request with a named example:** resolve the named entity first when its ID, type, or canonical link is needed. Then retrieve the wider market evidence before composing the answer. The named entity remains supporting evidence, not the deliverable. - **Company financial context:** when an eligible sector, deal, or thematic overview explicitly names a small company cohort, use company financial history only as supporting evidence. Normally make no more than three company-financial calls. Never activate this skill for standalone company financial history. - **Granular portfolio, asset, company, valuation, risk, structural, or operating detail:** complete the supported market overview and describe the MCP boundary conservatively. - **Hedge funds:** use funds, managers, investors, and news. Do not force private-capital deals, benchmarks, secondaries, or fund-performance tools into the workflow. ### Internal fundraising-currentness checks The fund endpoint has no last-updated, fundraising-activity-date, status-effective-date, or interim-close-date filter. Historical records may retain raising or interim-close statuses after they stop describing the current market. Apply these checks internally: - Use `current year - 1` through `current year + 1` as the default diagnostic vintage window. - Use `current year - 3` through `current year + 1` only when the narrow window is too sparse or the user asks for a wider view. - Keep active/open statuses (`Raising`, `Open to Investment/Raising`, `Open for Investment`) separate from interim-close statuses (`First Close` through `Sixth Close`). - Keep `Announced` and evergreen or open-ended vehicles separate. - Treat all status totals as candidate records, not a verified live fundraising census. - Treat a status view as unusually broad when either active/open or interim-close records exceed 500, or when the two groups together exceed 1,000. Apply thresholds and routing decisions silently. Never mention a "reasonableness gate", threshold, diagnostic screen, or other skill mechanic in the user-facing answer. When the status view is unusually broad, omit the count from the executive read and Key Indicators unless the user explicitly requests it. Emphasize ranked targets, dated closes, strategy composition from a complete cohort, or current signals instead. If currentness remains material, state only the consequence: the MCP does not provide enough status-timing information to verify a current fundraising census. An aggregate reported target size may be used only when the complete relevant cohort is retrieved within the row limit, records are deduplicated, target-size values are usable, and currentness is not materially misleading. Label it as the **sum of reported target sizes** for the defined cohort, not capital raised. State the usable-value denominator in prose when material. Do not aggregate a top-N page. The manager field `total_funds_in_market` is a manager-level reported field. Do not sum it across managers as a market fund count. ## 4. Normalize filters separately for each tool Preqin tools do not share one universal taxonomy. Validate values separately for every selected module. Call each matching discovery tool once per tool/filter domain per answer before applying categorical filters. Reuse the discovered values across pagination, alternate sort orders, ranked views, and equal-period comparison calls. Repeat discovery only when the scope changes materially, a new filter domain is introduced, or the server rejects a categorical value. Core pairs include: - `preqin_fund_filter_values` before categorically filtered `preqin_funds` calls. - `preqin_fund_manager_filter_values` before categorically filtered `preqin_fund_managers` calls. - `preqin_investor_filter_values` before categorically filtered `preqin_investors` calls. - `preqin_deal_filter_values` before categorically filtered `preqin_entity_deal_history` calls. - `preqin_secondaries_filter_values` before categorically filtered `preqin_secondaries` calls. - `preqin_news_filter_values` before categorically filtered `preqin_news` calls. - `preqin_pc_benchmarks_filter_values` before broad benchmark calls using `strategy` or `region_name`. A `fund_id`-only benchmark call does not require categorical discovery. For supporting-only specialist routes, use the discovery pairs in `references/preqin-tool-routing.md`. Do not rerun discovery for page changes, date-window comparisons, or numeric-range changes when the categorical scope is unchanged. Request only the filter metadata needed by the selected modules. Use `preqin_search` when a named entity must be resolved to an ID. For an explicitly named supporting example, resolve it before broader market calls when downstream tools or link rendering need the ID. Reuse each resolved ID and canonical URL throughout the response; do not search incidental names from returned records by default. Deal IDs come from deal history, not search. Use only exact parameter and column names from the current MCP schema. Never infer field names from display labels or examples. For `preqin_funds`, identity fields such as `fund_id`, `fund_name`, and `fund_url` are returned automatically and must not be added to `columns`; use `vintage`, not `vintage_year`. If a parameter or column is rejected, inspect the live schema and retry once with an exact supported name rather than guessing variants. Do not silently broaden or narrow the market because an exact filter is unavailable. State the user-relevant scope consequence, not the internal mapping process. For country-level requests, validate what each module can express. The fund tool filters investment focus by region rather than country. For a request such as US private equity, either use North America as an explicitly broader fund-focus proxy or omit the fund module. Never use fund domicile as investment geography. Manager and investor country describe organization location; deal country describes the target or transaction location. Manager and investor tools use the combined `PE` code for private equity and venture capital. For buyout-only or venture-only questions, keep those totals as broader PE/VC context and normally out of the executive read and Key Indicators unless the user asks for ecosystem size. ### News geography and visible-use rules The news endpoint has no country or region filter. For a geographically scoped overview: 1. Retrieve a recent bounded set of news for the relevant asset class and analytical categories, normally 20 to 30 records ordered by date descending; retrieve up to 50 when needed to identify a useful set of geographically relevant stories. 2. Inspect `headline` and, when necessary, `news_detail`. 3. Use a record as regional evidence only when the story explicitly names the requested country or region, names a fund or mandate with that focus, or states that the planned investment, commitment, search, transaction, or other activity targets that geography. 4. Do not infer investment geography from the firm's headquarters, domicile, or the investor's own location. 5. A multi-region story may be used when the requested geography is explicitly included; label it as multi-region context. 6. Exclude records whose geographic relevance cannot be established from the returned content. Do not use them to calculate a regional total, share, or trend. Treat this as semantic selection from a globally retrieved news set, not as a complete regional news universe. When repeated records describe the same story, consolidate them by `news_id` where available, or otherwise by the same headline and date, while preserving materially different named participants. If news is queried and relevant records are returned, use them visibly in Key Indicators, Market themes, or Market activity and participants. If news does not materially contribute to the answer, do not list it as evidence used in Data coverage. Mention an exclusion only when it materially explains why a requested current-signal view could not be provided. ## 5. Retrieve data efficiently and transparently Use pagination metadata and bounded retrieval deliberately: - For a count only, use `page_size: 1` and treat `total` as matching records or rows. - For largest, latest, or otherwise selected records, normally use `page_size: 10` with an explicit sort or an explicit thematic inclusion rule. - When geographically filtering news from story content, normally retrieve the latest 20 to 30 relevant asset-class records so that suitable regional stories are not missed simply because they fall outside the first page. - Before displaying any bounded record table, define its selection basis: the eligible population, ranking or recency field, sort direction, and material date, status, strategy, or geography filters. - Use `page_size: 50` when row-level calculations require records. - Retrieve a complete filtered result only when it contains no more than 200 records, using no more than four pages by default. - Do not retrieve more than 200 rows from one module unless the user explicitly requests exhaustive analysis and the tool supports it. For tools with a `columns` argument, select only fields that will be used in the answer. Do not request long text unless it is necessary. Distinguish internally among: - Matching-record totals from tool metadata. - Metrics from a fully retrieved universe. - Metrics from a defined cohort. - Ranked or recent slices. Never call a first page or top-N list a representative sample. Treat metadata totals as matching records, not guaranteed unique entities or transactions. Deduplicate complete cohorts by stable ID before calculating unique counts. State user-relevant geography meaning where it affects interpretation: fund geography is normally investment focus; manager and investor geography is organization location; deal geography is target or transaction location. ### Keep internal mechanics internal Routing, validation, currentness, plausibility, deduplication, retry, and benchmark-matching rules are analysis controls. Apply them silently. Do not expose: - Skill rules, thresholds, or "gates". - Tool-routing choices or retry logic. - Result ordering, such as whether the correct benchmark was the first row. - Individual duplicate IDs or low-level deduplication steps. - The names of internal checks. Surface only the consequence that matters to the user, for example: - The data do not support a verified current fundraising count. - Transaction totals are presented as records rather than verified unique deals. - The benchmark was matched by vintage, strategy, and region. - The current MCP did not return enough information for the requested conclusion. Discuss technical methodology only when the user asks for it. ### Evidence prominence Prioritize evidence in this order: 1. Equal-period event comparisons supported by date filters. 2. Matched market benchmarks. 3. Dated or explicitly ranked records. 4. Internally consistent manager, investor, or current-signal records. 5. Fundraising status totals and combined-taxonomy universe counts. Do not let a large but weakly current status total dominate stronger dated evidence. ## 6. Apply data-quality checks before interpreting results ### Freshness Determine freshness separately for each module using the relevant returned date. Do not present one universal as-of date when modules differ. ### Missing values, consistency, and disclosure - Treat null or absent values as unknown, never zero. - Treat zero in a field that is normally positive as anomalous unless the source semantics establish that zero is valid. - Flag or omit percentages outside 0-100. - When both values are positive, treat investor allocation or manager asset-class AUM more than 5% above total AUM as anomalous unless a defensible reporting-basis explanation is returned. - Do not silently repair anomalous records. - Calculate deal-size, transaction-price, or other optional-value statistics only over usable disclosed values. - Do not mix deal size, enterprise value, post-money valuation, target size, fund size, or final-close size. Inspect disclosure internally whenever it determines whether a value-based conclusion is valid. Do not create a standalone **Disclosure** row in Key Indicators unless the user explicitly asks for disclosure coverage as the subject of the analysis. Mention disclosure in prose or Data coverage and limitations only when it materially constrains a conclusion or the user asks specifically about values. When mentioned, state the usable numerator and denominator. ### Dates - Compare consistent, non-overlapping periods. - Flag future-dated records and exclude them from completed historical calculations unless clearly expected or scheduled. - Treat partial months, quarters, or years as partial. - Do not silently correct dates. ### Fundraising currentness Apply the internal fundraising-currentness checks above. In the user-facing answer, state only the analytical consequence. Do not name the thresholds or internal decision rule. ### Currency and field meaning - Prefer USD-normalized fields for cross-market comparisons. - Do not sum local-currency values across currencies. - Use manager `ac_aum_usd_mn` for asset-class scale, not total firm AUM. - Use investor `asset_class_allocation_usd_mn` and `asset_class_allocation_pct` for asset-class exposure. - Keep differently named fields from different endpoints separate unless the source contract establishes equivalence. ### Deal status and uniqueness - Inspect status coverage before relying on a status filter. - For BUYOUT, VC, PD, and INF, `Completed` is normally appropriate when populated. - For RE, status may be null. If a `Completed` query returns zero but an otherwise equivalent query returns records with null status, use identical unfiltered-status queries for both periods and describe them as recorded transactions. - Deduplicate complete cohorts by `deal_id` before reporting unique counts. - If uniqueness cannot be established, use record or row language. - Do not identify individual duplicate records in the user-facing answer unless the user asks for methodology. ### Performance and benchmarks When performance is used within market context: - Report requested fund count, returned fund count, and performance as-of date. - Match benchmarks by exact vintage first, then confirm strategy and region. - Compare only metrics present for both fund and benchmark. - Consider called capital and DPI when available. - Keep `Most Up-to-Date` separate from a precise date; it does not supply an exact composition date. - Do not reconcile profile fund size with performance commitment size unless the source contract supports it. Describe the matched peer group without discussing result ordering or internal selection mechanics. ## 7. Calculate only supported metrics Permitted calculations include: - Matching-record counts from returned metadata. - Equal-period deal or news comparisons using the same filters. - Growth rates when comparable period totals are directly available. - Disclosure rates for internal quality assessment or value-focused requests. - Counts, shares, medians, percentiles, and distributions from a fully retrieved universe or clearly defined cohort. - Top or latest records based on an explicit sort. - Benchmark medians returned directly by the benchmark tool. - Sum of reported target sizes for a fully retrieved, deduplicated, clearly defined fundraising cohort with usable target values. Do not infer or calculate: - Market distributions from a partial ranked page. - Total market deal value when value disclosure is incomplete. - Historical allocation trends from a current investor snapshot. - Market sentiment from a small set of news records. - Granular asset, company, holding, portfolio, valuation, risk, leverage, term, maturity, exposure, or operating conclusions unless the needed fields were returned. - Unique transaction counts from metadata when uniqueness has not been established. - Causation from coincident changes. Separate observation from interpretation. Use cautious language for inference. ## 8. Produce a consistent, evidence-based market brief Unless the user requests another format, use the following top-level sections in this order. Omit a section only when it has no meaningful supported content. Do not invent alternative headings merely for variety. # [Market] Market Overview **Scope:** State the asset class, strategy, geography, event period, and material defaults in one compact paragraph. ## Executive read Give a concise synthesis of the most important supported findings. Prefer dated trends, matched benchmarks, and clearly ranked records over weak status totals. Do not discuss internal checks or tool mechanics. ## Key indicators Use this table schema: | Dimension | Metric or observation | Current value | Context / comparison | Coverage / as-of | |---|---|---:|---|---| There is no fixed row count. Review every selected module and include all distinct, decision-useful indicators that materially help the user understand the market. Do not default to five rows or prune supported indicators merely for brevity. Where the data support them, consider separate indicators for deal activity, fundraising scale or composition, manager scale, investor allocation or recorded plans, benchmark context, secondary-market activity, and current signals. Avoid padding: each row must add a distinct market insight rather than repeat another row in a different form. For **Context / comparison**, use the strongest valid option available: 1. Equal-period historical comparison. 2. Matched benchmark comparison. 3. Like-for-like cross-sectional comparison. 4. Related status, strategy, or pipeline context. 5. Concise scope or freshness context such as `Snapshot only`, `No historical series`, or `Latest available record`. Do not manufacture a comparison. Do not use generic `n/a` when a concise reason is more informative. Every Key Indicators row must contain an observed value or a defensibly derived calculation. Omit rows whose current value would be `Not returned`, `Not exposed`, `Unavailable`, `Unknown`, `No data`, `n/a`, or an equivalent placeholder. If missing coverage materially limits the answer, explain the consequence once in Data coverage and limitations instead of listing absent metrics individually. Do not include by default: - A standalone disclosure-rate indicator, unless the user explicitly asks for disclosure coverage. - A row whose only value is that a module or field is unsupported, not exposed, missing, or zero because nothing was returned. - Internal validation outcomes, thresholds, or routing decisions. - Combined PE/VC manager or investor totals in a narrow buyout-only or venture-only overview unless ecosystem size is relevant to the request. If an unsupported dimension was explicitly requested, explain it in Data coverage and limitations instead. ## Market themes Present the supported themes that explain what is happening. For each theme: 1. State the observation. 2. Give the evidence. 3. Explain the interpretation. 4. Note a material limitation only when it affects the interpretation. ## Market activity and participants Include only records that materially support the themes. Use neutral, criterion-based subheadings such as: - `Largest active/open fundraising records by reported target size` - `Most recent completed transactions` - `Largest returned managers by reported asset-class AUM` - `Recent investor plans explicitly referencing the requested geography` Every bounded, ranked, recent, or curated table must state immediately below its heading why the records were included. The selection note should identify: - the eligible market population; - the ranking or recency field and sort direction; - material date, status, strategy, asset-class, and geography filters; and - whether the records were selected thematically rather than ranked. For example: > *Selection: largest returned 2025-2027 Europe-focused private-debt funds coded active/open, ranked by reported target size descending.* > *Selection: most recent completed transactions in the stated market and period, ordered by deal date descending.* > *Selection: latest private-debt news whose returned headline or detail explicitly references Europe as an investment geography, ordered by date descending. Multi-region plans are included only when Europe is named.* For a thematic rather than ranked list, explain the analytical reason, for example: `Selection: recent records that directly illustrate the sector-mix theme, ordered by date descending.` Do not use a generic heading such as `Selected recent records` without explaining whether the rows are largest, most recent, highest allocation, highest AUM, or selected for an explicit thematic reason. When investor plans or current-signal news provide distinct, relevant evidence, consider them for Key Indicators as well as this section. Keep them clearly labelled as recorded plans or observed signals, not complete market demand. If news was retrieved and used, make its contribution visible in this section or another analytical section; do not mention news only in Data coverage. Avoid subjective labels such as `Leading`, `Top players`, or `Dominant` unless a complete and defensible metric supports them. Preserve every canonical Preqin link returned by the source tools and reuse it wherever the same entity appears. When an important entity is returned only as text, resolve and link it selectively only when it is explicitly named, analytically material, ambiguous, or one of a small number of prominent examples. Normally perform no more than three to five enrichment-only entity resolutions per answer, deduplicate names first, and leave incidental names as plain text. Never guess a URL from a name or URL pattern. ## Data coverage and limitations Keep this section concise and user-relevant. State the consequences of missing, stale, partial, inconsistent, or non-comparable data without narrating internal mechanics. List only modules that materially contributed evidence to the answer. Do not say that news was used merely because the endpoint was queried; if retrieved stories were excluded because regional or thematic relevance could not be established, mention that only when it materially affects the requested analysis. Examples of useful limitation language: - Fundraising status timing is not sufficient to verify a current market census. - Deal values are too sparsely reported to support a market-wide value trend. - Manager and investor geography describes organization location rather than investment destination. - Transaction totals are matching records rather than verified unique deals. - The current MCP did not return a dedicated series for the requested dimension. Do not name reasonableness gates, row-order decisions, retry behavior, individual duplicate IDs, or excluded anomalous records unless the user asks for methodology. ## Further Preqin context Include this optional section only when it adds real value. Use conservative wording: - Preqin Pro may offer broader or more granular information, subject to asset class, dataset coverage, and the user's access. - Preqin research may provide complementary analyst commentary and market context. - Preserve relevant Preqin Pro links returned by the MCP. Do not list specific additional fields or claim specific research coverage unless verified for the relevant asset class or source. A user-specified format overrides this standard structure. Otherwise, keep the section order stable while allowing the analysis, number of indicators, themes, examples, and overall length to adapt to the evidence. Do not shorten a customer-facing answer merely to mirror the length of a regression test or another response. Do not add a separate follow-up section by default. A single concise next-analysis suggestion may be added at the end only when it is clearly useful and supported by available tools. ## 9. Handle ambiguity, errors, and unsupported requests - If the market is ambiguous, ask one focused question and stop. - If no records match, state the user-relevant scope and filters; do not fill the gap with general knowledge. - If one optional module fails, continue with supported modules. Mention the missing module only when it materially affects the answer. - Retry an invalid categorical filter once after re-checking live filter values. Do not expose retry mechanics to the user. - For real-estate status gaps, use recorded-transaction language when required. - If sparse data prevent a reliable overview, provide a narrower factual snapshot. - If an optional unsupported dimension was not central to the request, omit it rather than placing it in Key Indicators. - If the user explicitly requested an unsupported dimension, explain the limitation in Data coverage and limitations and provide the supported market context. - If the user's sole request is exact granular data outside the MCP, explain the integration boundary and suggest Preqin Pro conservatively. - If a named fund remains the primary subject of a performance or benchmark request, do not activate this skill, even when the user adds incidental market or peer context. Use fund-level evidence only inside a genuinely market-first overview. - Never invent records, values, links, classifications, benchmarks, dates, research conclusions, or tool results. ## 10. Supporting resources Consult these packaged references: - `references/preqin-tool-routing.md`: detailed tool sequences, fields, sorts, and fallbacks. - `references/preqin-taxonomy.md`: cross-tool asset-class, strategy, geography, status, and entity mappings. - `references/data-quality-and-metrics.md`: calculations, coverage, currentness, plausibility, and evidence rules. - `references/examples-and-edge-cases.md`: activation, presentation, and fallback examples. This `SKILL.md` controls if a reference conflicts with it. ## 11. Activation examples Requests that should activate this skill include: - "Give me an overview of North American private debt." - "Give me an overview of private equity in North America." - "What is happening in European infrastructure fundraising and deals?" - "How active is the private-equity secondary market?" - "Give me a European private-debt market overview and include Apollo among the manager examples." - "Who is allocating to infrastructure, and what are the latest signals?" - "Give me a real-estate market overview and tell me where I can explore more detail." - "Summarize venture fundraising trends and point me to relevant Preqin research." Requests that should not activate this skill include: - "What is the S&P 500 doing today?" - "How has Blackstone Capital Partners VIII performed relative to its benchmark?" - "How does Apollo compare with its private-debt peers?" - "Summarize CalPERS' private-equity commitments." - "Which investors are known across KKR's funds?" - "How has this company's revenue and EBITDA evolved?" - "Show me every underlying asset in this one fund" when no market context is requested. - "Who are the service providers for this fund?" - "Give me Blackstone's contact details." - "Profile this fund" when no market context is requested. - "Tell me which private-markets fund I should invest in." ## Version history - **v0.14** (2026-09-01): Corrected MCP tool names and discovery routes; rebuilt the live tool index; added market-first company-financial context with strict scope limits; clarified cached discovery; and made specialist entity routes explicitly supporting-only or outside scope. - **v0.13** (2026-09-01): Clarified that market-first refers to the deliverable rather than the first tool call; required early resolution of explicitly named supporting entities when needed; added selective, deduplicated hyperlink enrichment with a soft call cap; strengthened canonical-link reuse and exact-schema discipline; and aligned named-manager examples and regression tests with the controlling workflow. - **v0.12** (2026-08-27): Required every bounded or curated record table to state its observable selection basis; added semantic geographic filtering of globally retrieved news using headline and detail content; required news to be visibly used when counted as evidence; and added consolidation and completeness safeguards for repeated or regionally classified news records. - **v0.11** (2026-08-27): Made the entity-first exclusion explicit even when incidental market or peer context is added; clarified that named entities may appear only as supporting examples inside genuinely market-first overviews; and reinforced that customer-facing indicator breadth and output length should follow the available evidence rather than regression-test conventions. - **v0.10** (2026-08-27): Encouraged fuller Key Indicators coverage without a fixed count; required every indicator row to contain observed or derived data; removed placeholder rows for absent metrics; strengthened the named-entity activation exclusion; and promoted relevant investor plans and current signals into indicator selection. - **v0.9** (2026-08-27): Standardized the market-brief section order; kept internal skill mechanics out of user-facing output; removed disclosure and unsupported-item rows from default Key Indicators; added neutral record labels, conservative Preqin Pro and research positioning, stronger investor-plan and news routing, aggregate target-size safeguards, and a tighter single-fund activation boundary. - **v0.1-v0.8** (2026-08-26): Established the Preqin MCP market-overview workflow, supporting references, data-quality controls, live-test refinements, and the `Context / comparison` indicator format.
Technical details
- First seen
- Sep 30, 2026 · 22:02 UTC
- Last seen
- Oct 2, 2026 · 00:00 UTC
- Collection status
- Collected
plugin_asdk_app_6a97e10f874c81918821f8633151efd3
Download plugin data (JSON)