Builders in Fintech

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so safety and idempotency are covered. The description adds that the response contains coverage, citation, and download-location content, which is useful but shallow; it says nothing about format, size, or whether it is static server metadata.

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?

A single front-loaded sentence listing three concrete payloads with no filler. Every clause earns 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?

With no parameters and no output schema, the description needs only to say what the agent gets back, and it does so for all three content areas. Given the simplicity of a zero-argument metadata tool, this is essentially complete.

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 the baseline of 4 applies. There is no parameter semantics to document, and the description correctly avoids inventing any.

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 concrete content the tool surfaces: database coverage, citation guidance, and bulk download locations. It is clearly distinct from all data-retrieval siblings like get_content or search_organizations, though it opens with a noun phrase rather than a verb+resource pair.

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: an agent would infer it should call this to orient itself before using the data tools, but the description never says when to call it or that it is a prerequisite/entry point. No alternatives or exclusions are named, though none are really needed given the unique meta role.

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 safety (readOnly, idempotent, closed-world), lowering the bar, and the description still adds a genuinely useful semantic caveat: rounds/per_currency/undisclosed count equity only while by_category covers all categories, so the category split can exceed the round count. This is non-obvious behavioral context that prevents misreading the numbers.

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, zero waste. The output scope is front-loaded, and the qualifier about equity-only vs all-category counting is placed as a clear 'Note:' where it matters most.

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 burden of explaining the return shape, which it largely does by enumerating rounds, countries, per-currency totals, undisclosed, and by_category. It stops short of exact key names or empty-slice behavior, but is otherwise complete for calling the tool 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 the four filter parameters are fully documented in the schema (date formats, slug/ISO handling). The description adds only the framing that filters define 'a slice' and does not elaborate on how from/to/topic/country combine. Baseline 3 is appropriate 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.

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

The description states a specific purpose: producing aggregate counts (rounds, countries, per-currency totals, undisclosed, per-category) for a filtered slice of the funding database. An agent can distinguish this aggregation tool from the list/search siblings, though it never names them explicitly. Clear but not sibling-routed.

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 via 'a slice of the funding database' plus the optional filter parameters. There is no explicit when-to-use or when-not-to-use guidance, and no pointer to alternatives like list_funding_rounds or largest_rounds for row-level data. Adequate but leaves routing to inference.

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, closed-world), so the description's value is in return behavior: body text is truncated, related entities are attached, and news items carry a corrections array ordered newest first. That is genuinely useful context, though error behavior for an unknown slug is not addressed.

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, front-loaded with the core action and zero filler. The corrections clause is niche but justified because there is no output schema to carry return-shape detail.

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 does the work of describing the return payload (body, topics, countries, organizations, people, corrections), which is appropriate for a two-parameter read. It leaves out only edge cases such as unknown-slug behavior, a minor gap.

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%, with slug and the content_type enum fully documented, so the baseline is 3. The description restates 'by type and slug' and implicitly links the corrections array to the 'news' type, adding slight meaning but no format or syntax 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?

States a specific verb and resource ('One published item by type and slug') and enumerates the returned facets, so the agent knows this is a single-item fetch rather than a search. It does not, however, name or distinguish itself from the sibling search_content, so the retrieval path is only inferable from the shape of the inputs.

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 phrase 'by type and slug' implies the caller must already hold both identifiers, which is weak usage guidance. There is no explicit when/when-not and no routing to search_content for discovery, so the agent must infer that this tool is the follow-up to a search rather than a lookup entry point.

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: amounts are never converted, published values are frozen while revised_* carries later corrections, coverage_affected/coverage_note flag skewed baselines, minimum sample sizes (5) are stated, and unknown arguments are rejected. This is unusually rich behavioral context for a read tool.

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 resource, then arguments, then index mechanics, then caveats. Dense but each clause carries information. The methodology/field-name sentences (revised_*, coverage_note) are the least economical, though they stand in for a missing output 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?

With no output schema, the description usefully names output concepts (Count Index formula, USD median index needing 5 rounds, revised_*, coverage_affected, coverage_note). It is nearly complete, though the exact response envelope/field layout is still 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 description coverage is already 100%, so baseline is 3, but the description adds real meaning: the 'YYYY-Www' format with a concrete example ('2026-W39'), the omit-for-latest behavior, and the 1–104 range for weeks. Marginal value above 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?

States a specific verb+resource: 'Get ... the weekly Builders Fintech Funding Index of approved equity rounds (ISO weeks)'. The resource is narrowly scoped and clearly distinct from siblings like funding_summary or largest_rounds, which do not produce an index.

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?

Explains the two usage modes precisely: pass 'week' to get a specific ISO week, omit it to get the latest weeks newest-first, with 'weeks' controlling quantity. It does not explicitly name an alternative sibling or say when to prefer this over funding_summary/largest_rounds, so it stops short of a full when/when-not statement.

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 behavior. The description adds the non-obvious conditional-return rule (requires min_eligible companies) and the exact eligibility criteria (first backed at least window ago, later round at least gap_days after entry), which is valuable context beyond the annotations.

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-loads the core purpose, but then repeats 'Arguments: slug (required)' which is redundant with the schema, and the long eligibility clause is dense and could be split. It's not wasteful, but it's not maximally tight either.

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 single-parameter read-only tool with no output schema, the description covers the metric definition, eligibility conditions, and return condition. An agent has enough to call it correctly. Missing only alternate-tool routing, which is a minor gap.

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 schema fully documents the only parameter (slug). The description correctly identifies slug as required but adds no format or sourcing detail beyond the schema's 'Investor slug from its URL.' Baseline 3 is appropriate when schema does the heavy lifting.

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+resource: 'Follow-on scorecard for one investor by slug.' The metric is precisely defined (share of portfolio companies that raised a later approved round within the window). It doesn't distinguish itself from siblings like most_active_investors directly, but the unique metric makes its purpose unmistakable.

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 implies when the tool returns data ('Only returned when the investor has at least min_eligible eligible companies') and mentions window/gap_days, but it never names an alternative tool or explicitly states when to use this versus most_active_investors or other investor tools. Usage context is implied, not guided.

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 readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description still adds real context beyond that: it enumerates what the read returns and flags a provenance caveat that 'products (company-provided, not part of the CC BY dataset)' — a licensing/trust distinction an agent could not get from the annotations.

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?

One sentence, front-loaded with the core operation ('Full public profile for one organization by slug') before the enumeration of contents. Dense but every clause carries information, though the long list of returned sections pushes toward run-on territory.

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 carries the return-value burden and does so well by enumerating the profile's sections (funding rounds, people, coverage, disclosure, products). It stops short of any error/not-found behavior or pagination note for large profiles, which leaves a small gap.

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?

There is a single required parameter with 100% schema description coverage, so the baseline is 3. 'By slug' mirrors the schema's own wording and adds no format, casing, or lookup guidance beyond it.

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 ('Full public profile for one organization by slug') plus the title clarifies it covers companies and investors. This implicitly separates it from search_organizations (search vs. keyed fetch), but no sibling is named explicitly, so differentiation is left to inference.

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: 'by slug' plus the schema note 'Organization slug from its URL' tells an agent it needs a pre-known identifier, which mildly implies when this beats a search tool. However, no explicit when-to-use or when-not-to-use guidance and no alternatives (e.g., search_organizations) are named.

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 readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is fully covered without the description. The description adds value by indicating this returns the 'Full public profile' (i.e., the complete record rather than a search snippet), but says nothing about pagination, errors, or auth.

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?

One front-loaded sentence naming the resource, lookup key, and returned fields with zero filler. Every clause carries information.

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 simple single-record read with no output schema, the description compensates by enumerating the returned fields (bio, roles, coverage). Annotations cover the safety semantics, so nothing critical is missing, though it could note behavior for an unknown slug.

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?

There is a single parameter with 100% schema description coverage, and the schema already explains that the slug comes from the person's URL. The description repeats 'by slug' without adding format or lookup guidance, 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?

Specific verb (get) plus resource and scope: a single person's 'Full public profile' looked up by slug. It is clear what is returned (bio, roles, coverage). It does not explicitly name search_people as the discovery alternative, so it falls short of a 5.

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: 'by slug' signals you must already have a slug, which an agent can infer comes from search_people. There is no explicit when-to-use/when-not statement or named alternative, so this is minimum-viable guidance.

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/closed-world, so the bar is lower, and the description adds real value beyond them: data provenance ('company-provided, not part of the CC BY dataset') and a neutrality guarantee ('sponsorship never changes ordering') that an agent could not 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-loads the scope, then lists fields, then appends provenance and ranking caveats — all in three tight clauses with no filler. Slightly dense but every clause earns 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?

With no output schema, the description compensates by naming the return fields and the metadata envelope (provided_by, last_confirmed_at, sponsored). For a read-only single-record lookup this is close to complete; only pagination/error behavior is unaddressed, which is largely irrelevant here.

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?

Single slug parameter with 100% schema coverage, where the schema already explains 'Product slug from its URL.' The description adds no format or sourcing detail beyond the schema, 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 verb and resource ('Full public listing for one product by slug') and enumerates the returned fields, which cleanly separates it from the sibling search_products (retrieval by slug vs. query). An agent can tell what it gets 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?

Usage is only implied: 'by slug' signals the input needed, and the sibling search_products is the natural alternative, but the description never says when to prefer this over searching. No explicit exclusions or prerequisites are given.

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/no open world, so the safety profile is covered. The description adds a genuinely useful behavioral fact the annotations cannot: amounts are never converted across currencies, which changes how an agent should interpret results.

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?

One sentence, front-loaded with the ranking behavior and the currency caveat. Nothing is pad or redundant.

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, and the description omits defaults for year/per_currency, the sort order, and response shape. The key interpretive caveat (no currency conversion) is present, so it is adequate but not complete for a ranking 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 coverage is 100% with only two optional params (year, per_currency), so the schema carries the load and a baseline of 3 applies. The currency note tangentially explains per_currency's meaning but adds no default value or range guidance beyond the schema's '≤200'.

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?

Names a specific resource (disclosed equity rounds) plus the differentiator (ranked largest, per currency). That ranking scope separates it from list_funding_rounds and most_active_investors without needing 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?

Usage is implied by the name and description ('largest' ranking), but there is no explicit statement of when to prefer this over list_funding_rounds, funding_summary, or most_active_investors, and no exclusions or prerequisites.

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 readOnlyHint, idempotentHint and a closed (non-openWorld) scope, so the safety profile is covered externally. The description adds meaningful domain context by stating that only countries with public coverage are returned and that counts accompany each entry, but says nothing about ordering, pagination, or freshness.

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?

A single tight sentence with no filler and the key filter front-loaded. It is efficient, though it reads more like a fragment than a full instruction.

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 and no parameters, the description carries the return-value burden and does name the payload (company and content counts), which is the main thing an agent needs. It stops short of describing the shape of those counts or how countries are identified, leaving a small gap for a zero-param discovery 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?

The tool takes zero parameters, so the baseline of 4 applies. There is nothing the description could add about argument semantics, and the schema is trivially complete.

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 (implicit 'list') and resource (countries), plus the filtering condition ('with public coverage') and the payload ('company and content counts'). It does not explicitly distinguish itself from similar enumerations like list_topics or list_events, but the resource is unambiguous.

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?

No when-to-use guidance, no prerequisites, and no mention of alternatives (e.g., about or list_topics) even though the sibling list shows several enumeration tools. The agent must infer that this is a lookup/discovery call.

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 readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds the meaningful curation detail that only 'approved' events are returned and that upcoming is the default, which is real context beyond the annotations, but says nothing about result count caps or payload shape.

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?

A single front-loaded sentence that puts the resource and default scope first and the optional filters second, with no wasted words.

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 six-parameter, all-optional read tool with a fully documented schema and no output schema, the description covers scope, default and filter surface. Only the result ordering/return shape is left implicit, which is a minor gap.

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 description is not required to document the six filters; it mirrors them (country, format, topic, month) and adds the notable default that upcoming=true, which is stated in the schema too. Baseline 3 is appropriate.

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 sentence names the resource (fintech events), the default scope (upcoming) and the qualification (approved), so an agent can tell exactly what this returns. It does not need to name a sibling because no other tool in the list deals with events, but it also does not explicitly state the 'list' verb.

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 by 'upcoming by default' and the filter list — an agent infers this is the browse-all path when no specific event or organization is targeted — but there is no explicit when-to-use/when-not statement or named alternative.

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 (readOnlyHint, idempotentHint, openWorldHint=false), so the description's real contribution is behavioral: results are restricted to 'Approved' rounds, ordered newest-first, and paged via a keyset cursor. Naming the returned next_cursor fields (after_date, after_id) is meaningful, since there is no output schema. No rate limits or page-size behavior beyond the schema's limit are mentioned.

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 no filler, and the key facts (scope, ordering, pagination) are front-loaded ahead of the cursor instruction.

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 11 optional params, no output schema, and full schema coverage, the description supplies the missing pieces an agent needs: the 'Approved' scope, sort order, and how to fetch subsequent pages. It does not cover what a row contains, but the absence of an output schema plus the cursor hint keeps this adequate rather than deficient.

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% and already documents all 11 filters, including the cursor pair. The description adds only the framing that after_date/after_id are pagination cursors returned by the API, without expanding on any other parameter's meaning; baseline 3 is appropriate.

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+resource ('Approved funding rounds') plus ordering ('newest first') and the capability set ('optional filters and keyset pagination'). An agent knows it is a filtered list of funding rounds, though it never explicitly contrasts itself with siblings like largest_rounds or funding_summary, which also surface round data.

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 makes clear this is the general-purpose filtered listing and explains how to paginate, which implies its usage context. However it gives no explicit when-to-use/when-not or routing guidance against close alternatives such as largest_rounds and funding_summary, leaving selection to inference.

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 establish readOnlyHint=true, idempotentHint=true, and closed-world scope, so safety and repeatability are covered. The description adds only that the set is 'every public topic' with slug and URL; it says nothing about ordering, pagination, or result size for what could be a long list.

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?

A single sentence that front-loads the resource and payload, then gives the intended use. Nothing is wasted and nothing needs to be reread.

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 parameters, no output schema, and annotations covering the safety profile, the only real burden is describing the return contents, which it does (slug and URL, public topics). An ordering or pagination note would make it fully self-sufficient, but the gaps are minor for a simple enumerator.

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 the baseline is 4. There is no parameter surface for the description to clarify or compensate for.

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 and resource ('Every public topic') and states the payload shape ('with its slug and URL'), so an agent can immediately tell what it returns. It does not explicitly contrast itself with the similarly named siblings (list_countries, list_events), but the resource is unambiguous.

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?

It states the intended role clearly: the returned slugs are meant to be used as filters in the other tools. That tells the agent when to call it (before a filtered query), though it names no specific alternative tool or exclusion condition.

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 read-only/idempotent safety. The description adds meaningful behavior beyond them: only approved rounds are counted, category defaults to equity, and country filtering restricts to companies headquartered there. It does not disclose sort order direction or tie-breaking, but the counting semantics are a genuine addition.

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?

Three sentences, ranked criterion front-loaded, no filler. Dense but every clause carries filtering or default information; only the country format restatement is redundant with 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?

No output schema exists, yet the description conveys what is returned (a ranking of investors by approved-round count) and how filters affect it. Adequate for a simple read-only ranking tool whose annotations cover the safety profile.

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 all five parameters (from, to, limit, country, category) are already documented. The description restates the country slug/ISO and equity-default details rather than adding new syntax, so it earns only the baseline.

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+resource+ranking criterion: investors ranked by the number of approved rounds they appear in. An agent can distinguish this from list_funding_rounds or funding_summary, but no sibling is named explicitly to disambiguate against get_investor_scorecard.

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 explains filter semantics (country scoping, category default) but gives no when-to-use or when-not-to-use guidance. Nothing tells the agent how this ranking differs from get_investor_scorecard or largest_rounds.

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 readOnlyHint=true, openWorldHint=false, and idempotentHint=true, covering the safety profile. The description adds useful behavioral context beyond annotations: a minimum query length of 2 characters, the absence of a plain-list mode, and that unknown arguments are rejected. It does not describe return format or pagination, but the added constraints are meaningful.

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 description is two sentences: first the purpose, then the argument constraints. It is front-loaded, has zero waste, and every clause earns its place by specifying scope and key requirements.

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 simple read-only search tool with 100% schema coverage and annotations that cover safety and idempotence, the description is nearly complete. It clearly states the required query, minimum length, no plain-list mode, and strict argument handling. A brief note on the return shape or default limit would make it fully complete, but those are minor given the schema and no 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 description coverage is 100%, so the schema already documents all four parameters including the 'q'/'query' alias and the 'kinds' and 'limit' fields. The description repeats the required/minimum aspects of 'q' but adds no syntax, format, or filtering semantics beyond what the schema provides. Baseline 3 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.

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

The description states a specific verb ('Full-text search') and enumerates the resource scope ('published news, newsletter issues, podcast episodes and public entity pages'), so the agent knows exactly what content is covered. It does not explicitly differentiate from sibling search tools like search_organizations or search_people, so a 4 is appropriate.

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 implies usage by stating that the tool has no plain-list mode and that 'q' is required, which tells the agent it must provide a search term. However, it gives no explicit when-to-use versus alternatives, no comparison to sibling search tools, and no exclusions beyond the plain-list note.

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 establish read-only, idempotent, and non-openWorld semantics, and the description adds real behavioral detail on top: default page size of 25 and that unknown arguments are rejected. It also notes returns are public profiles with canonical URLs, though it says nothing about pagination beyond the 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?

Front-loads the purpose in the first sentence, then handles scope and arguments compactly with no filler. The 'Arguments:' enumeration is slightly list-like but every clause carries information.

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 partially compensates by noting the return shape (public profiles with canonical URLs) and error behavior for unknown arguments. For a zero-required-param search tool this is close to complete, with only pagination beyond the default left implicit.

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 schema already documents q, kind, limit, query alias, and country. The description only adds marginal value, notably that q is matched against the name, plus a restatement of the alias and no-q behavior; the baseline of 3 is correct here.

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 (search) and resource (fintech companies and investors) plus the filterable facets (name, kind, country). This clearly distinguishes it from siblings like search_people, search_products, and search_content, which target different resource types.

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?

Explains the no-q case (plain alphabetical list, first 25 by default), which is useful context, but never states when to prefer this tool over the near-identically named siblings such as search_content or get_organization, nor any exclusions.

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 safety (readOnly, idempotent, closed-world), so the bar is lower; the description still adds real behavior: the default result count of 25 and the fact that unknown arguments are rejected. It does not disclose pagination or result shape, but the added details go meaningfully beyond the annotations.

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 purpose in the first clause, then terse structured notes on arguments and defaults. The argument recap partly duplicates the schema, which costs a little, but nothing is padded.

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 parameterless-required, read-only search tool with no output schema, the definition covers purpose, both call modes, aliasing, error strictness, and the default row count. Only pagination/result-shape guidance is absent, which is minor given the read-only annotations.

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 adds the default-25 cap that the schema's limit field does not state, and clarifies the q/query alias resolution, which is also covered but reinforced. Marginal but genuine added 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 (search) and resource scope (founders, operators, investors covered by the publication), which implicitly separates it from siblings like search_organizations and search_products. It stops short of naming or contrasting any sibling tool explicitly, so it is clear but not fully differentiated.

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 explains the two modes (with q = match on name, without q = alphabetical list), which implies when each is appropriate, but never states when to prefer this tool over get_person or other search_* siblings. Usage is inferable rather than instructed.

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 read-only/idempotent/closed-world safety, but the description adds real value: the content is unverified guest speech, pagination runs through cursor from the previous page, and the qa array is returned only when q is given and only honours q and episode. That conditional return behavior is not derivable from annotations or schema.

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 provenance before the argument list, and each clause carries information. It is dense with some repetition of schema-documented fields, which keeps it from 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, so the description usefully covers return shape (qa array conditions) and pagination via next_cursor, plus the rejection of unknown arguments. Complete enough for an 8-param filter tool, though it could note result ordering beyond 'newest facts'.

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 every parameter is already documented, and the description largely restates the same field meanings (q/query alias, organization, person, fact_type, episode, limit, cursor). It adds little syntax or format detail beyond the schema, so the baseline of 3 is appropriate.

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 (search) and resource (attributed facts and Q&A pairs) and scopes the source (Builders in Fintech podcast episodes). The provenance caveat 'as stated by the guest, not independently verified' sharply distinguishes this from search_content and other sibling 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?

Gives concrete context: with no q it lists the newest facts, q matches fact text/questions/answers, organizations are slugs, and unknown arguments are rejected. It does not explicitly say when to prefer this over search_content or get_content, so it falls short of naming alternatives.

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?

Adds substantive context beyond the annotations: results are company-provided rather than CC BY, each row carries provided_by/last_confirmed_at/sponsored, and sponsorship explicitly never affects ordering (a trust-relevant disclosure). It also warns that unknown arguments are rejected, which is a behavioral constraint not visible in the schema.

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-loads purpose and result-metadata facts before the argument list, with no filler sentences. It is dense but every clause carries information an agent needs; slightly packed, but not padded.

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 naming the key result fields (provided_by, last_confirmed_at, sponsored) and the pagination contract via cursor/next_cursor. With all 8 parameters schema-documented, an agent has enough to call it correctly, though the full result shape remains 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 the baseline is 3, and the description goes beyond it by specifying that q matches against name and short description and that query is an alias with q taking precedence. That adds real meaning about matching behavior and parameter conflict resolution.

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 (search) and resource (fintech products) and enumerates the facets it searches over: text, category, market, API availability, customer type. This clearly distinguishes it from siblings like get_product (single-product lookup) and search_organizations/search_people.

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 concrete operating conditions: use q/query for text search, omit q for a plain alphabetical listing, and pass cursor for the next page. However, it never names the alternative tools (e.g. get_product for a known product) or states when this tool is the wrong choice, so routing guidance is implied rather than explicit.

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