Read-only search over the Founder Ventures library on bootstrapped SaaS, plus founder events.
Scored across 3 tools
Each tool targets a distinct resource+action: listing events, searching the content library, and fetching a page. The read and search tools are complementary rather than overlapping, and read_founder_ventures_page explicitly points to search_founder_ventures for URL discovery.
All three names follow a clean snake_case verb_noun pattern (list_, read_, search_), making the action intent immediately predictable. No convention mixing.
Three tools is small but each serves a clear, non-redundant role for a read-only content/events site. Slightly lean, though justified by the narrow scope.
Search plus page-fetch covers content retrieval, but there is no way to enumerate all articles, browse by category, or paginate results — only keyword search and a separate events listing. Notable gaps for a library-style domain.
Curated startup and founder events in European tech cities, filtered for tech-founder relevance and refreshed daily. Omit city to list the supported cities.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City slug. Omit to list supported cities. | |
| when | No | upcoming | |
| limit | No |
| Name | Required | Description |
|---|---|---|
| city | Yes | City slug, or null when listing supported cities. |
| when | Yes | |
| error | Yes | Set when the city slug is unknown. |
| cities | Yes | Supported cities. Filled only when `city` is omitted. |
| events | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuine traits beyond them — a daily refresh cadence and curated tech-founder filtering — but says nothing about pagination behavior despite a limit parameter and default.
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?
Two tight sentences with the resource scope front-loaded and the city-omission behavior second; nothing is padded. The second sentence duplicates the schema's `city` description, a minor redundancy.
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?
A read-only listing tool with rich annotations and an output schema needs only scope and behavior stated, which the description largely delivers. The remaining omissions — limit/pagination semantics and any routing hint versus the sibling venture tools — are modest given the structured fields already present.
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 33%: only `city` is documented in the schema, and the description merely repeats it ('Omit `city` to list the supported cities'). The `when` and `limit` parameters go unexplained beyond self-evident enum values and a default, so the description neither compensates for the gap nor adds meaning.
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?
The description names the resource precisely ('curated startup and founder events in European tech cities') along with its scope and curation intent. It does not explicitly contrast with the siblings read_founder_ventures_page and search_founder_ventures, though the events-vs-ventures noun distinction makes them separable.
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?
Usage is only implied: 'filtered for tech-founder relevance and refreshed daily' signals the intended audience, and 'Omit `city` to list the supported cities' gives one operational instruction. There is no explicit when-to-use-this-vs-siblings guidance or condition for choosing among the three event/venture tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the markdown source of a Founder Ventures page. Pass a site-relative path such as / or /glossary/product-led-growth, typically one returned by search_founder_ventures.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Site-relative path, e.g. `/playbooks/cold-email-that-converts`. | / |
| Name | Required | Description |
|---|---|---|
| url | No | Canonical https://founderventures.io URL. |
| path | Yes | |
| found | Yes | False when the path has no markdown representation. |
| title | No | |
| markdown | No | |
| updatedAt | No | Last update date (YYYY-MM-DD), when known. |
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, covering the safety profile fully. The description's one addition is that the payload is markdown source, and since an output schema exists even that is largely covered. It adds modest value over 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?
Two sentences, no filler: the action and return format come first, then the parameter guidance. Every clause carries information an agent needs.
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?
Single required parameter, full schema description coverage, a rich annotation set, and an output schema, so the description need not explain returns or safety. The remaining job — how to form the path and where it comes from — is done.
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 would be 3, but the description adds meaning beyond the schema by supplying concrete path examples (`/`, `/glossary/product-led-growth`) and explaining where paths typically originate (search_founder_ventures), which helps an agent construct a valid value.
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 (Fetch), resource (a Founder Ventures page), and output form (markdown source), which is enough for an agent to differentiate it from search_founder_ventures and list_founder_events 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?
Gives clear context: pass a site-relative path, 'typically one returned by search_founder_ventures', which establishes the search-then-read workflow. It stops short of explicit when-not-to-use guidance or naming an alternative reader, so it is clear context rather than full routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword search over the Founder Ventures library on bootstrapped B2B SaaS: growth playbooks, PLG glossary, case studies, tool comparisons, and original research. Returns titles, descriptions, and site-relative URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return. | |
| query | Yes | Search terms. |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world scope, so the safety profile is covered. The description adds useful corpus scope (what content is searchable) and the shape of returned fields, but says nothing about ranking, pagination of the result set, or behavior on zero matches. With annotations carrying safety, a 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences, front-loaded with the verb and resource, then the corpus contents and return shape. No filler or redundant restatement of the title.
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 an output schema present and rich annotations, the description need not explain return values in depth; it covers purpose, corpus, and result fields. The only real gap is routing guidance relative to the sibling tools, which is minor for a low-complexity two-parameter search.
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% — query and limit are both documented in the schema, so baseline 3 applies. The description mentions no query syntax, matching behavior, or how limit interacts with results, so it adds nothing beyond the schema.
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?
The description gives a specific verb ('Keyword search') and resource ('the Founder Ventures library'), and enumerates the corpus types (growth playbooks, PLG glossary, case studies, tool comparisons, research). It does not explicitly contrast itself with siblings read_founder_ventures_page or list_founder_events, so the distinction is inferable rather than stated.
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?
Usage is implied: 'keyword search' suggests this is the discovery/entry tool versus reading a specific page, but there is no explicit 'use this when…' or 'for X use Y instead' guidance. With three plausible siblings and no routing instructions, the agent must infer the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
list_founder_eventsread_founder_ventures_pagesearch_founder_venturesRead-only search over the aidata.stream documentation, blog, changelog, pricing and FAQ.
Read-only search over the Vocenya AI receptionist API docs and endpoints, with code samples.
Search cited playbooks from top founders and investors on growth, distribution and pricing.
Search InvestorMatch's public directory of VC investors and fundraising guides. No sign-in needed.
Add one secure layer between your agents and this server.
