Fund Momentum

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

Annotations already declare read-only, idempotent, closed-world and non-destructive, and the description goes well beyond them: cost is free and keyless, it consumes a 10/day keyless allowance but never agent credits or quota, and counts under 5 are bucketed as "<5" with zero reported as "none". These are exactly the operational facts an agent needs before deciding to spend a call.

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?

Strongly front-loaded with "START HERE" and the output contract established early. The cost information is duplicated nearly verbatim at the end (free / never billed / 10-call keyless allowance), which is the one clearly redundant block — that repetition earns a small deduction rather than a 5.

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?

With no output schema, the description nonetheless pins down the return contract (counts only, "<5" threshold, "none" for zero) and the cost/rate-limit profile. For a two-optional-parameter coverage-check tool this leaves nothing material unspecified.

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?

Schema coverage is 100%, so country (full name or ISO code, undisclosed HQ excluded and surfaced as undisclosed_hq_count) and lp_type (enum with spelling normalisation) are already fully documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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?

States a specific question it answers ("does Fund Momentum cover my geography and LP type") and the exact shape of the answer (counts only, with a count of emerging-manager-backed LPs). It explicitly negates what it does not return (names, slugs, websites, commitments), which separates it cleanly from search_lps.

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?

"START HERE for any question about limited partners" plus "Call this before search_lps to find out whether LP Radar covers what you need" gives an explicit ordering rule and names the alternative it gates. An agent knows both when to call it and what to do next.

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

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

Goes well beyond the readOnly/idempotent annotations: discloses the 7/30/unlimited window tiers, that truncation is surfaced via since_floor_applied rather than silent, that empty polls are free but still pace-limited, and the credit cost model. It also enumerates the change_type values and explains what close_updated carries.

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?

Front-loaded with the core distinction and the cost note, and most sentences earn their place. The cost model is restated twice (the 'COST:' sentence near the top and the closing 'Cost: free with no key...' paragraph), which is the main redundancy dragging it below a 5.

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?

No output schema exists, and the description compensates fully: it describes the unchanged response shape, the row contents, the change_type enum, and the last_close block with its fields. An agent can parse the response and design a polling loop from this text alone.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds operational meaning the schema lacks: send both next_since and etag together, and an unchanged window yields `unchanged: true` with no rows. The limit parameter is left entirely to the schema, which is acceptable given full coverage.

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?

States a specific verb and resource ('return only the funds whose data changed since a given timestamp') and immediately frames the scope as incremental sync rather than discovery. This makes it unambiguously distinguishable from search_funds and get_fund among the siblings.

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?

Explicitly says when to use it ('FOR STAYING CURRENT, not for discovery') and names the alternative it replaces ('Use this instead of re-running search_funds on a schedule. One call here replaces a full re-crawl'). Both the positive case and the anti-pattern are stated.

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

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds real substance: the provenance block per field, last_close contents, confidence reporting, and the resolved_from marker. The only weakness is an internally inconsistent cost message — 'free, no API key required' up front versus '1 credit (EUR 0.01) per call on an agent key' at the end.

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?

Front-loading with 'THEN:' is effective, but the cost model is stated twice in different terms, and the provenance/last_close sentence is a dense run-on. The content is useful; the packaging wastes space and creates ambiguity.

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?

With no output schema, the description carries the return-shape burden and does it: provenance, last_close, resolved_from, and the confidence notion are all named. Cost, resolution quirks, and slug provenance are covered, so an agent has everything needed to call it correctly.

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?

Schema coverage is 100%, so baseline would be 3, but the description adds meaning beyond the schema by explaining why the slug cannot be derived from the display name and what happens when a near-miss occurs. That is behavioral guidance the schema types alone do not convey.

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?

States a specific verb and resource ('get the detailed profile of one fund') and pins the input to a slug returned by a named sibling. An agent can distinguish this from search_funds or get_fund_signals without opening a schema.

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?

Explicitly sequences the workflow ('THEN... using a slug returned by search_funds'), states a negative rule ('Do not guess the slug... it will usually be wrong and the call is wasted'), and documents edge-case routing (near-miss resolves only on exactly one match; ambiguous names are listed, not guessed).

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

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely useful beyond-schema context: pricing model, ~96% signal coverage, and that not_found is returned before payment so a bad slug is never charged. This is above the annotation baseline but the cost is stated twice, diluting the value.

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 opening sentence is well front-loaded and the coverage/not_found detail is valuable. However the cost is stated twice in near-identical form ('COST: included in Pro, or €0.10 per call over MPP if you have no key' and the trailing 'Cost: included in Pro; otherwise EUR 0.10 per call...'), so one full sentence does not earn its place.

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?

No output schema exists, so the description must describe returns, and it does so concretely (thesis, signals, dos/don'ts, deployment status, source URLs). Pricing, failure behavior and preconditions are all present — nothing an agent needs to call correctly is missing.

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?

Schema coverage is 100% and there is only one parameter, so the schema already documents the slug format and its provenance. The description restates the 'call search_funds first' guidance, adding no new syntax or format detail beyond what the schema says.

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?

States a specific verb (drill down) and resource (investor signals for a fund), and enumerates the payload: GP thesis, bullish/contrarian signals, founder dos and don'ts, deployment status, source URLs. It also distinguishes itself from search_funds and get_fund, which are named directly.

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?

Explicit sequencing guidance: use after search_funds/get_fund, before writing outreach to a specific fund. The slug parameter description reinforces the dependency ('Call search_funds first rather than guessing').

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds genuinely new behavioral facts: the not_found short-circuit that happens before any charge, and the pricing model. It does not cover return shape or how many GPs come back, which is a modest gap rather than a serious one.

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 opening two sentences are front-loaded and tight, but the pricing is stated twice in near-identical wording ("COST: included in Pro, or €0.10 per call over MPP if you have no key" then "Cost: included in Pro; otherwise EUR 0.10 per call (10 credits) on an agent key, or the same amount paid inline over MPP with no key"). That duplication costs the definition a point on structure.

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?

For a 2-parameter read tool with no output schema, the description covers purpose, prerequisites, failure mode, and cost. What its return actually looks like is only implied ("who to approach and what they personally focus on"), which is adequate but not fully closing the gap left by the absent output schema.

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?

Schema coverage is 100% and the fund_slug schema text already says "exactly as returned in the `slug` field of search_funds," so the description's restatement of that requirement adds little. The optional gp_name filter is never mentioned; 3 is the correct baseline when the schema does the work.

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?

"DRILL DOWN to the people: General Partner profiles for a fund you already identified" gives a specific verb (drill down / retrieve profiles), a specific resource (GP profiles), and an explicit scope (a fund already identified). It is cleanly distinguishable from get_fund, which covers the fund itself.

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 states the selecting condition outright — use it when the question is who to approach and what they personally focus on, rather than what the fund does — which routes the agent away from get_fund. It also states the prerequisite (requires a slug from search_funds) and a when-not case (a fund with no published GP data returns not_found).

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds materially more: the call is free, requires no API key, and crucially does NOT consume the keyless 10-calls-per-day allowance, though it is still subject to the per-minute pace limit. That metering nuance is exactly the kind of non-obvious behavior an agent needs and cannot infer from structured fields.

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?

Front-loaded with the trigger phrase and the cost facts, then a single dense sentence enumerating return fields. It loses a point for redundancy: 'Cost: free' appears twice (once as 'COST: free', again as a trailing 'Cost: free' line) and 'Never charges anything' restates the same idea a third time.

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?

There is no output schema, so the description carries the return-value burden itself — and it does, listing every notable field including resets_at and credits for agent keys. Combined with the zero-parameter schema and full annotation coverage, an agent has everything needed to call this correctly and interpret the result.

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 tool takes zero parameters, so there is nothing to disambiguate; baseline is 4. The description correctly implies no inputs are required by presenting the call as unconditional.

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?

States a specific verb and resource ('get usage') and enumerates exactly what comes back: tier, calls used/remaining per window, credits for agent keys, resets_at, and per-minute pace limit. It also frames the user intent it answers ('how many calls or credits do I have left'), so an agent can match it to a query without opening the schema.

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?

'START HERE for ...' gives an explicit entry-point trigger for quota questions. No alternatives are named, but the sibling tools are all unrelated domains (funds, LPs, changes), so there is no real overlap to disambiguate against — the only gap is the absence of a stated when-not, which matters little here.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds high-value operational context: a 3-10 second latency because it reasons over every tracked fund, plus an explicit instruction to allow for that rather than timing out and retrying. The cost model is also spelled out.

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?

Front-loaded well with the entry-point distinction and the search_funds contrast, but the cost information is stated twice ('COST: included in Pro, or €0.25 per call over MPP' and then a near-identical 'Cost:' sentence), which is redundant bloat.

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?

With no output schema, the description correctly explains the return shape (top 10 funds, slug, reason, score) and adds latency and pricing, which is what an agent needs to decide and to wait. Only the duplicated cost sentence detracts.

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?

Schema description coverage is 100%, so both 'stage' and 'country' are already documented, including enum normalization. The description adds nothing about the parameters themselves, so the baseline 3 applies.

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?

States a specific action and its output precisely: describe a startup in plain language, receive the top 10 matching funds with slug, reason and score. It also positions itself against the sibling search_funds, so an agent can tell the two apart without opening either schema.

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?

Explicitly names when to use this ('when you do not know what to search for', qualitative briefs like 'climate hardware, pre-seed, Europe') and when to use the alternative (search_funds for filters). Both the positive and negative conditions are stated.

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

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

Annotations already declare read-only, idempotent, closed-world, so the safety profile is covered. The description goes well beyond that with the economics that actually constrain a call: 1 credit per fund returned, a keyless free tier, per-call defaults and hard caps, and a billing object in the response. The cross-reference of limits to the plan tiers is a bit tangled (the schema carries the authoritative version), but the behavioral picture is clear.

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?

Front-loaded with the highest-value directive ('START HERE'), and each paragraph covers one concern: what it does, how to use the slug, cost. It loses a point because the Cost paragraph duplicates defaults and caps that the schema already states in more precise form ('Default limit 10. Default max_credits 10, hard maximum 25 per call').

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?

Seven all-optional parameters, no output schema, yet the description enumerates the returned fields (name, slug, country, stage, fund size, industries, lastCloseDate, lastCloseType, durable URL), names the routing convention, and spells out the cost model. An agent has everything to decide, call, and interpret the response without opening the schema.

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?

Schema coverage is 100%, so the baseline is 3. The description earns above-baseline for two things the schema doesn't state: closed_since returns results newest-close-first, and the slug it returns is the input every other tool requires. It also flags the close definitions (first/interim/final, or a launch) rather than relying on the schema's date format alone.

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?

States a specific verb and resource ('Search actively deploying venture capital funds') plus the dimensions it filters on, and immediately distinguishes itself from siblings by declaring itself the entry point ('START HERE for any question about funds'). An agent can tell this is the discovery tool and get_fund/search_lps are not.

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?

Explicit when-to-use ('START HERE for any question about funds'), a conditional branch ('For which funds just closed, pass closed_since'), and a dependency rule tying it to every other tool ('run this first and copy the slug rather than constructing one from a fund's name'). It says when this tool is the right call and how its output feeds siblings.

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

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.

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.

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.

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.

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.

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.

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

Goes well beyond the annotations (which only say it is a non-destructive, non-idempotent, closed-world write): the call is free, needs no API key, does not consume the keyless 10/day quota, is capped at 5 per caller per UTC day, stores one short message and triggers no notification or reply. It also states a data-handling rule (no third-party personal details, no documents or credentials), which is exactly the kind of policy an agent cannot infer elsewhere.

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?

Front-loaded with the purpose and the cost picture, then the behavioral reality, then the privacy rule — a sensible order. The only waste is the redundant trailing "Cost: free" after already saying "COST: free, no API key required" in the opening, plus the duplicated privacy caveat already present in the schema.

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?

There is no output schema, and the description compensates by stating outright that only a message is stored and nothing else happens — no notification, no reply — so the agent knows what a call does and does not return. Quota, cost, auth requirements and privacy constraints are all covered, leaving no material gap for a 3-parameter feedback tool.

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?

Schema description coverage is 100%, so the baseline is 3; the description earns above that by adding substance the schema does not, namely that the message should be generic and must exclude third-party personal details, documents and credentials, and by implying brevity ("one short message"). It adds no per-parameter detail for category or tool_name, which keeps it out of 5 territory.

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?

States a specific verb and target ("Tell the Fund Momentum team") plus the exact scope of acceptable input ("a bug, a data problem or a missing feature"). This is unmistakably the only write/reporting tool among read-only siblings like search_funds and get_fund, so an agent can select it without inspecting any schema.

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?

Gives clear triggering conditions (bug, data problem, missing feature) and implicit constraints on use through the per-caller daily cap of 5. It also sets expectations that no reply will come, which discourages using it as a request channel. It stops short of naming an explicit when-not-to-use rule or an alternative path, so not a 5.

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