Skip to main content
Glama

Fund Momentum

by io.github.schneidavie
OverviewDiscussionsAdmin

Search LP records

search_lps
Read-onlyIdempotent

THEN, for LP Radar subscribers: return limited partner records (name, slug, LP type, HQ country and city, geographic focus, website, emerging-manager backing, verified flag) filtered by country, LP type and emerging-manager backing, at most 25 per call. Set backs_emerging_managers=true to see only LPs that have already backed a first or second fund — for a first-time manager that is usually the only filter that matters. Requires LP Radar (EUR 199 per month or EUR 1,499 per year, https://fundmomentum.vc/lp-radar). Not available per call, on agent credits or on the keyless trial. Unlimited calls for subscribers. Use check_lp_coverage first — it is free and tells you whether the dataset covers your geography and LP type before you pay anything. Send the API key of the account that holds LP Radar. A caller without it gets error_reason "lp_access_required" together with the coverage count for its filters, never a payment challenge. website is null when no website is on record; it is never omitted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoRecords to return, 1-25. A value above 25 is rejected, not clamped.
countryNoHeadquarters country of the LP, spelled out in full (e.g. 'Germany'). Two-letter ISO codes are accepted too.
lp_typeNoLP type. Must be one of the listed values; common spellings such as 'family office' or 'pension' are accepted and normalised.
backs_emerging_managersNotrue returns only LPs that have backed an emerging manager; false returns only those that have not. Omit for both. Not available on check_lp_coverage, which reports the figure as a breakdown instead.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / backs_emerging_managers
      Added value: +{
+  "description": "true returns only LPs that have backed an emerging manager; false returns only those that have not. Omit for both. Not available on check_lp_coverage, which reports the figure as a breakdown instead.",
+  "type": "boolean"
+}
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare this a safe idempotent read, and the description goes well beyond them: subscription/auth requirements, the exact failure mode ('lp_access_required' plus coverage count, never a payment challenge), and null-handling for website. This is unusually complete behavioral disclosure.

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?

Dense but every sentence carries operational weight (auth, error contract, null semantics, filter advice). The opening 'THEN, for LP Radar subscribers' is an awkward fragment that delays the core purpose, costing a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by listing returned fields, and it covers prerequisites, auth, error behavior, and filter semantics. An agent has everything needed to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds interpretation the schema lacks — that backs_emerging_managers=true means LPs that have backed a first or second fund, and that this filter is absent from check_lp_coverage. It adds meaning rather than restating the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('return limited partner records') and enumerates the returned fields, the filter dimensions, and the 25-record cap. It is clearly distinguishable from siblings like check_lp_coverage and search_funds.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: 'Use check_lp_coverage first — it is free', and gives conditional advice ('for a first-time manager that is usually the only filter that matters'). It also names who can call it (LP Radar subscribers) and who cannot (per-call, agent credits, keyless trial).

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

All Fund Momentum toolsInspect
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.

Resources