BPJ Startup Research

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

Annotations already declare readOnly=true, destructive=false, openWorld=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: processing is local retrieval with neural representation and no external LLM, output is source-linked, and a data-handling rule (don't send customer secrets). It does not explain the non-idempotent hint, but overall it adds real 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?

Three tight sentences that front-load the purpose and outputs with no filler. The unexplained "MEMBER:" token is wasteful but the rest 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?

For a complex tool with 10 undocumented parameters and no output schema, the description describes the deliverable (source-linked plan, evidence, economics) adequately but leaves the full parameter surface unexplained. It is minimally complete about the result, incomplete about the inputs.

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 0% across 10 parameters, so the description must carry the load and largely does not. Only faint inferences are possible: "unit economics" loosely maps to price/budget/fixedCost/variableCost, and "14-day" hints at hours. Required parameter "question", plus skill, stage, customer, and language, receive no explanation at all.

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 ("build") and resource ("14-day validation plan") and enumerates concrete outputs: opposing success/failure evidence, unit economics, and website-upgrade suggestions. This is much clearer than a tautology, but it never explicitly distinguishes itself from the siblings (compare_startup_cases, get_startup_radar, search_startup_cases, startup_preview). The cryptic "MEMBER:" prefix adds no clarity.

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?

There is no when-to-use guidance and no named alternative among the four sibling tools, so an agent cannot tell from the description alone when to build a plan versus comparing, searching, or previewing cases. "Do not send customer secrets" is a constraint, not usage direction.

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 read-only, non-destructive, closed-world safety profile. The description adds useful behavioral constraints about retaining metric periods, team evidence, limits, and never converting revenue to profit, though auth or membership requirements are not fully explained.

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 compact sentences with no wasted text. The action and scope are front-loaded, and the behavioral constraint is stated directly.

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?

Covers the core comparison purpose and some data-handling behavior, but with no output schema and an undocumented language parameter, the definition leaves some invocation-relevant details unstated. Annotations cover safety, but return semantics and parameter usage are only partially addressed.

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 0%, so the description must document both parameters. It clarifies that ids correspond to 2–4 reviewed cases and implies same-customer-job scope, but it says nothing about the language parameter or its zh/en enum.

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 (compare), resource (reviewed cases), and scope (2–4 cases for the same customer job). It is distinguishable from search_startup_cases and startup_preview, though it does not explicitly name or contrast those 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?

Implies when to use it by requiring 2–4 reviewed cases for the same customer job, but gives no explicit when-not guidance, prerequisites, or alternatives such as search_startup_cases.

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/destructive/openWorld, so the bar is lower, yet the description adds real value: a membership requirement, a data-quality caveat ('unreviewed'), and explicit limits ('no revenue or solo verdict'). These are behavioral facts an agent cannot get from the 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 dense sentences, front-loaded with the access tier and the resource, then caveats. No filler, though cramming four distinct ideas into two sentences makes it slightly opaque.

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 5-param, no-output-schema read tool the description conveys the data sources and important caveats, but it leaves three parameters (focus, limit, language) undocumented and offers no guidance on result volume or ordering. Adequate but with clear gaps.

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 0%, so the description must carry the burden for 5 parameters. It only gestures at 'dates' and 'optional retained history' (loosely mapping to history) and the two sources; it says nothing about focus, limit, or language, leaving most parameters unexplained.

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 ('query') and concrete resources ('daily Show HN discussion samples and Product Hunt launches'), which is enough to distinguish it from the case-oriented siblings like search_startup_cases. It does not name any sibling explicitly, but the resource is distinct enough that an agent can route to it.

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?

There is no when-to-use, when-not-to-use, or alternative named. The 'MEMBER:' prefix hints at an access tier but gives no guidance on when an agent should pick this radar over search_startup_cases or startup_preview. Usage must be inferred from the resource alone.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds two useful behavioral facts: the default scope excludes company references, and relevance does not imply success probability. It does not mention the 'MEMBER:' access implication, result limits, or pagination behavior.

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 tight, front-loaded sentences with no filler. The 'MEMBER:' prefix and the terse relevance caveat are slightly cryptic but cost little space.

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 6-parameter search tool with zero schema descriptions and no output schema, the description leaves most parameters unexplained and says nothing about result shape or limits. The read-only annotations cover safety, but the query surface remains largely undocumented.

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 0% across 6 parameters, so the description must compensate. It only hints at the scope default ('excludes company references'), leaving query semantics, the outcome enum, category, language, and the limit cap entirely undocumented in both places.

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 a specific verb+resource: 'find source-backed AI startup cases, with dated revenue/adoption/failure evidence.' That is clearly distinct from siblings like compare_startup_cases and build_startup_plan. It stops short of explicitly differentiating itself from get_startup_radar, which sounds adjacent.

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 line 'Relevance is not success probability' and 'Default excludes company references' give implied usage context, but no alternative tool is named and no when-not-to-use condition is stated. An agent must infer that scope/outcome parameters select the search mode rather than being told.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-annotation context — it is free, requires no key, and carries limits/caveats plus membership information. Those additions are real but vague: the limits and caveats are never specified, and no rate or quota behavior is disclosed.

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 short sentences with no filler, and the most decision-relevant facts (free, no key needed) are stated up front. The only soft spot is the trailing 'limits and caveats' clause, which spends words without conveying specifics.

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, zero-required-param, read-only tool with no output schema, the description covers identity, cost and authentication adequately. It still leaves two gaps an agent would want: what the preview actually returns (data vs. explanatory content) and what the language parameter does.

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 one optional parameter (language, enum zh/en) with 0% schema description coverage, so the schema does not compensate. The description never mentions the language parameter or what effect it has on output, leaving the agent to infer that it controls response language. With low coverage and a non-empty parameter list, the description should have carried this burden and does not.

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 it exposes (dated business evidence and launch signals) and frames it as a free preview, so an agent can broadly tell what it returns. However, the verb is fuzzy — it is unclear whether the tool returns sample data, documentation about the product, or both, since 'explains membership access, limits and caveats' reads like meta-content rather than a data operation. It also does not distinguish itself from siblings such as search_startup_cases or get_startup_radar.

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?

'Free preview' and 'no key needed' imply the usage context: an unauthenticated or pre-membership agent exploring the service before committing to a keyed tool. That is meaningful implicit guidance, but there is no explicit when-to-use/when-not-to-use statement and no routing to alternatives like build_startup_plan or search_startup_cases.

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