fundz

Search product launches

search_products

Read-onlyIdempotent

Find product launches and updates. Search by launch type (New Product, Major Update, Feature Release), category (Software, Hardware, Service), and company.

Input Schema

Name	Required	Description
`days`	No	Number of days to look back (e.g., 7, 30, 60)
`page`	No	Page number, starting at 1 (default 1). Each page holds `limit` results; the reply ends with the total and next_page when there are more.
`limit`	No	Results per page (default 20, max 50)
`since`	No	Only results Fundz added on or after this ISO date, e.g. "2026-10-01" (whole day, so a daily run may repeat that day). Overrides days. Use the date of your last run to get only what is new.
`industry`	No	Industry title, e.g. "Information Technology"
`keywords`	No	Free-text keywords matched against title/description (comma-separated for several)
`location`	No	City, state or country title, e.g. "Texas"
`launch_type`	No	Type of launch: "New Product", "Major Update", or "Feature Release"
`company_name`	No	Filter by company name
`product_category`	No	Product category: "Software", "Hardware", or "Service"
`new_since_last_pull`	No	Only rows this account has not already been shown by an earlier new_since_last_pull call with the same filters. Fundz remembers per account and filter set, so a daily agent run gets just what is new, with no dates to track. The first call returns the normal window (days or since) and starts the marker. Ignores page: if more new rows are waiting the reply says so; call again the same way for the next batch. Needs a signed-in account.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 24, 2026

addedInput schema / properties / new_since_last_pull

Added value: +{
+  "description": "Only rows this account has not already been shown by an earlier new_since_last_pull call with the same filters. Fundz remembers per account and filter set, so a daily agent run gets just what is new, with no dates to track. The first call returns the normal window (days or since) and starts the marker. Ignores page: if more new rows are waiting the reply says so; call again the same way for the next batch. Needs a signed-in account.",
+  "type": "boolean"
+}

Changed3 schema fields changedOct 11, 2026

changedInput schema / properties / limit / description

Previous value: -"Maximum number of results (default: 20)"New value: +"Results per page (default 20, max 50)"

addedInput schema / properties / page

Added value: +{
+  "description": "Page number, starting at 1 (default 1). Each page holds `limit` results; the reply ends with the total and next_page when there are more.",
+  "type": "number"
+}

addedInput schema / properties / since

Added value: +{
+  "description": "Only results Fundz added on or after this ISO date, e.g. \"2026-10-01\" (whole day, so a daily run may repeat that day). Overrides days. Use the date of your last run to get only what is new.",
+  "type": "string"
+}

First observedOct 6, 2026

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already declare this as a read-only, idempotent, non-destructive, open-world search. The description adds little behavioral context beyond the purpose and a few filter examples, omitting notes on pagination, result limits, or how the new_since_last_pull mode behaves. With annotations covering the safety profile, a baseline 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose, and contains no redundant or filler text. Every phrase contributes directly to identifying the tool's searchable dimensions.

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

Completeness3/5

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

Given 11 optional parameters and no output schema, the description only highlights three filter dimensions and does not mention pagination, date-based filtering, or the important new_since_last_pull mode. The rich schema and annotations compensate, but the description itself is minimal for a tool of this complexity.

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%, so all 11 parameters are already documented in detail. The description only repeats the launch type values, category values, and company filtering, adding no meaningful semantics beyond what the schema provides. Baseline 3 is correct when the schema does the heavy lifting.

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 uses a specific verb and resource: 'Find product launches and updates.' It clearly identifies what is searched and lists several filter dimensions. However, it does not explicitly distinguish this tool from the many other sibling search tools such as search_major_events or search_funding_rounds.

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

Usage Guidelines2/5

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

The description states what the tool does but gives no explicit guidance on when to use it versus alternatives. It does not mention exclusions, prerequisites, or sibling tools. 'Find product launches and updates' is essentially a restatement of purpose, not actionable usage guidance.

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

All fundz 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.

Resources

Need Help?