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. Cost: included with LP Radar subscription

Input 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?

Despite readOnlyHint/idempotent annotations already covering safety, the description adds substantial behavior: paywall and price, required API key of the subscribed account, the exact failure mode (error_reason "lp_access_required" plus coverage count, never a payment challenge), a hard 25-record cap, and that website is null rather than omitted. This is disclosure beyond what annotations carry.

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 front-loaded, leading with access tier and returned fields before the filter guidance. Slight waste: the opening 'THEN' implies a workflow step without context, and the trailing 'Cost: included with LP Radar subscription' duplicates the pricing sentence earlier.

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?

No output schema exists, and the description compensates by enumerating return fields and the null-website convention. Auth, pricing, error semantics, and call cap are all covered, so an agent has everything needed to invoke it correctly or route away.

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; the description earns above that by adding interpretive value on backs_emerging_managers ('for a first-time manager that is usually the only filter that matters') and by noting that filter is unavailable on check_lp_coverage. The limit cap is repeated from the schema, which adds nothing.

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 and filters, so the agent knows exactly what comes back. It also names check_lp_coverage as the free precondition sibling, distinguishing it from the other search_* tools.

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?

Explicit routing: 'Use check_lp_coverage first — it is free and tells you whether the dataset covers your geography'. Also states when the emerging-manager filter is the only one that matters, and enumerates access modes that do NOT work (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