Mode VC: AI Venture Research Charts & Investor Atlas

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

Annotations already flag non-read-only, open-world and non-idempotent, but the description adds what those annotations cannot: exactly which fields go to Mode VC, that consent must be shown and affirmed by the founder, and that nothing is shared outside Mode VC. This is precisely the PII-disclosure context an agent needs before a one-way external submission.

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?

Purpose and target recipient are front-loaded in the first sentence, and every sentence addresses either fit, data handling, or a parameter. The privacy point is restated slightly ('goes to Mode VC' then 'nothing shared with anyone outside Mode VC'), 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?

For a one-way, open-world submission of personal data, the description covers recipients, consent gating, optional office hours, and the equivalent web form. It omits what the founder sees afterward (confirmation, recipient response, timing), which matters since there is no output schema to explain the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so the baseline is 3; the description goes further by enumerating the fields transmitted and imposing a workflow rule on `consent` (true only after the founder agrees) and a purpose for `office_hours`. It doesn't add format constraints beyond the schema, so it isn't a 5.

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 ('Sends a founder's pitch to the Mode VC team') plus concrete scope (pre-seed/seed AI, US$1M-5M checks). It explicitly routes to the sibling get_mode_vc_thesis_and_criteria for criteria, so an agent can distinguish the two without opening schemas.

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 for use (pitching Mode VC, mirroring the contact form) and names the thesis tool as the prerequisite/alternative for checking fit. It never states exclusions, e.g. what to do if the founder is past seed, so it falls short of a 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuine non-schema behavior: the modeling assumptions (top federal rates, no state tax or AMT) and a provenance/limitation caveat ('Illustrative model, not tax advice'). That is meaningful 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?

Three sentences, front-loaded with what is computed, then scope limitations and a reference URL. Every sentence carries weight, with only the model-provenance URL being marginally extraneous.

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 13-param, no-required-argument calculator with no output schema, the description communicates what the three output figures are and the key modeling caveats. It stops short of describing the response structure or units, which is the main remaining gap, but it is broadly complete for correct invocation.

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 each of the 13 parameters is documented with defaults and constraints, so the baseline is 3. The description adds no per-parameter semantics beyond implying a 'sale price' input; 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?

States three specific computations (83(b) deadline/tax, QSBS Section 1202 federal savings, Delaware franchise tax under both methods) with a clear verb+resource. This is plainly distinguishable from the sibling calculators like calc_burn_multiple_runway or calc_safe_dilution 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 implied by the tightly scoped purpose (compute these three tax figures), and the scope caveats ('federal tax only') help the agent decide if it fits. However there is no explicit when-to-use/when-not framing or routing to alternatives, so it stays at implied-usage level.

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, non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the 120-month search horizon, that month 1 is the current month, that it mirrors a specific web calculator's math, and that defaults align with the web version – all useful for interpreting 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?

Output list is front-loaded and dense, with the reference URL and horizon packed into a short block. Slightly overloaded by enumerating seven outputs in one run-on, but no sentence is wasted.

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 9-parameter, all-optional projection tool with no output schema, the description carries most of the load by naming the return metrics and the time horizon. It falls short only on how the two overrides change results and on the units/interpretation of 'default alive or dead', leaving 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?

Schema coverage is 100%, so every parameter including the two overrides is already documented in the schema. The description adds only the framing that growth rates drive projections and that overrides exist implicitly; it does not explain override precedence or interaction beyond what the schema states, so 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 (projects, month by month) and resource (cash/burn/runway) and enumerates the exact outputs: net burn, runway, zero-cash month, break-even, default alive/dead, burn multiple, and the expense-cut variant. This is precise enough to separate it from siblings like calc_saas_metrics 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?

The description implies usage by explaining defaults and that month 1 is the current month, but it never states when to prefer this over calc_saas_metrics or the other finance calculators, nor any exclusions or prerequisites. The 'omit to compute' guidance for overrides is present in the schema, not the description.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuine context beyond that: it ties the math to a specific source URL and warns that the ARR multiple is a heuristic, not a valuation, and the output is illustrative rather than legal advice.

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?

Four sentences, all of which earn their place, with the core action front-loaded before the sourcing and caveat sentences. Dense 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?

With 9 optional parameters and no output schema, the description explains the inputs conceptually but never states what the tool returns (equity percentages, advisor grant dilution, the multiple). It is adequate but leaves the output shape to inference.

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, including the 40/35/25 weights and web defaults. The description restates the weights and mentions the option pool and FAST grants but adds no syntax, format, or interaction 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?

The description states a specific verb and resource ("Splits founder equity") and names the exact inputs that drive it (weighted contribution scores, option pool, FAST grants, ARR multiple). An agent can distinguish this from calc_safe_dilution or calc_83b_qsbs_delaware by the contribution-score and FAST-grant mechanics, though no sibling is named explicitly.

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 specificity of the calculation, and the closing caveats ("rule of thumb, not a market valuation", "illustrative, not legal advice") scope when the output is appropriate. However, no alternative tool is named and no when-not condition routes the agent elsewhere among the many calc_* siblings.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds the scoring basis (weighted 12-item checklist) and clarifies the excluded email draft, but says nothing about return shape or edge-case handling.

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 front-loaded sentences with minimal waste: purpose first, then provenance and exclusion. The email-draft exclusion sentence is a useful boundary even if slightly expendable.

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 helpfully enumerates the outputs (overall, Corporate and Legal, each pillar, runway, burn multiple). It is complete enough that an agent can call it and interpret results, though exact return fields remain 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 100%, so the schema already documents all six parameters including web defaults and the omit-vs-empty-list behavior. The description adds no parameter-level meaning beyond that, so 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+resource: scores diligence readiness from a weighted 12-item data room checklist and computes runway and burn multiple. Clear, but it overlaps with the sibling calc_burn_multiple_runway without distinguishing itself from 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?

No explicit when-to-use guidance and no alternatives named, despite a sibling (calc_burn_multiple_runway) that also computes runway and burn multiple. The only scope note is that the email draft is excluded, which is not usage 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, non-destructive and closed-world, so the safety profile is covered. The description contributes real behavioral context beyond that: results are computed at list price, and the math plus a dated price file match the public modevc.com calculator, signalling deterministic parity rather than live market pricing. It does not state what the returned object looks like, but with no output schema an enumeration of computed figures partially covers that.

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, front-loaded with the verb and the headline outputs, mapping closely to what the tool returns. The output enumeration is long but each item earns its place; the trailing "compares 9 common models" fragment is the only weakly justified clause and is arguably inconsistent with the enum.

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 10 optional parameters and no output schema, the description carries the burden of telling an agent what comes back, and it does so by listing all five result families. What's missing is shape-level detail, such as whether margin output includes a break-even price per user or how savings are broken out, which matters for a calculator with no declared return type.

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 schema already explains each parameter, including defaults. The description adds directional meaning by naming prompt-cache savings and routing a share of requests to a cheaper model, but it does not clarify inputs the schema leaves thin, such as the interaction between route_model and route_share_pct or how target_margin_pct changes the output. The odd claim "compares 9 common models" against a 20-value enum adds no usable parameter guidance.

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?

Opens with a specific verb ("Estimates") and enumerates the exact quantities produced: monthly LLM spend, cost per user and per request, prompt-cache savings, routing savings, and gross margin. It also scopes the domain to models from Claude, GPT, Gemini, DeepSeek and Grok, which cleanly separates it from the equity, dilution and SaaS-metric calculators in the sibling list.

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 "for an AI product on any current Claude, GPT, Gemini, DeepSeek or Grok model at list price" gives a clear condition for reaching for this tool. It stops short of naming when not to use it or pointing at a sibling (e.g., a generic burn/SaaS calculator), so it sits just below the explicit routing seen in the strongest definitions.

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, non-destructive, closed world), so the bar is lower; the description adds genuine behavioral context beyond them — partial-input semantics yielding n/a, and a canonical external reference for identical math. It stops short of stating output shape, rounding, or unit expectations.

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, front-loaded with the metric list, then the partial-input rule, then the provenance link. Nothing is padded, though the external URL is the least load-bearing element for an agent.

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 14-parameter tool with zero required fields and no output schema, the description usefully explains that outputs degrade to n/a and that benchmarks accompany each metric. It never states the return format explicitly, which is the remaining gap given no output schema exists.

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 each of the 14 parameters is already annotated with its unit and the metric it feeds, so the description adds little. Its only extra is framing that all values come 'from the numbers you give'; baseline 3 applies 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?

Names a specific verb ('computes') and enumerates the exact metrics produced (Rule of 40, NRR, GRR, magic number, CAC payback, spend per new customer), which is a distinct scope from every sibling calculator (burn multiple, SAFE dilution, term sheet waterfall, etc.). An agent can route to this tool 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?

Gives clear operating context: 'Leave a group of inputs out to get n/a for the metrics that need it' tells the agent partial input is legal and how missing data is handled. It does not name when-not-to-use or point to an alternative sibling, but the metric list itself is the selection criterion.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds a useful caveat ('Illustrative model, not legal or tax advice') and notes pool pre/post-money mechanics, but says nothing about the return shape, which matters because there is no output 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?

Three compact sentences: the core model first, then the reference link, then the disclaimer. Every sentence carries information and the purpose is front-loaded, though the first sentence is dense.

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 an 8-parameter calculator with no output schema, the description explains what is modeled but never indicates what the tool returns or how results are shaped, leaving a real gap an agent would need to fill to use the output.

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 all 8 parameters are documented in the schema itself, including enums, defaults, and ranges. The description only hints at pool_mode ('pool in the pre-money or post-money') and stacked SAFEs, adding marginal value beyond the schema; 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: models SAFE conversion at a priced round, founder retention, and option-pool top-up treatment. The scope is narrow enough to separate it from calc_term_sheet_waterfall and calc_cofounder_equity, though no sibling is named explicitly.

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 it applies (stacked SAFEs converting at a priced round) and points to the reference web calculator for matching math, but it offers no explicit when-to-use vs. alternative guidance or prerequisites for the sibling calc tools.

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 non-destructive behavior, so the safety profile is covered. The description adds real value beyond that: it discloses the return shape (conversion point, sensitivity table, three structures side by side), the model's fidelity limits, and that the web calculator substitutes defaults for zero values.

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: the operation first, then the return contents, then the model limitations and reference URL. Every clause earns its place with no filler.

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 steps in to describe the returns (conversion point, sensitivity table, side-by-side structures) and bounds the model's assumptions. An agent has enough to call it and interpret results, though it doesn't specify units/format of the returned table.

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 enum constraints and zeroNote annotations on every parameter, so the schema carries the parameter burden. The description adds nothing parameter-specific beyond mentioning the participation options already enumerated in the schema; 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 and resource ('splits the sale proceeds between one preferred class and common holders') and enumerates the three participation modes it handles. An agent can distinguish this from siblings like calc_safe_dilution or calc_cofounder_equity without opening any schema.

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

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

The description scopes the model ('one preferred class, no seniority stack, no debt or fees'), which implicitly tells the agent when the output is not applicable. However, it names no alternative tool and gives no explicit when-to-use/ when-not-to-use guidance relative to the other calc_* siblings.

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

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

Annotations already declare the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description's job is lighter. It adds genuine context beyond them: the data is 'as published' on the chart page and original data must be fetched via source_urls — a useful fidelity caveat that tells the agent the returned table is a snapshot, not a live source.

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: the return payload first, then the lookup mechanism and the data-fidelity caveat. No filler, no restatement of the title, and the most important information is front-loaded.

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 describing returns — and it does so explicitly, naming every returned field plus the source_urls follow-up. For a single-parameter, read-only lookup already covered by annotations, nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and there is only one parameter, so the schema already documents that slug accepts a slug or title. The description's 'Look up by slug or title' largely restates the schema description rather than adding format, normalization, or failure-mode details (e.g., what happens on an ambiguous title match). 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 and resource — 'Returns one chart from the Chart of the Day archive' — and enumerates exactly what comes back (data table, claim, takeaway, note, sources). The single-chart, slug-or-title lookup framing distinguishes it from the search_charts sibling, so an agent can route correctly without opening either schema.

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

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

'Look up by slug or title' implies the usage context (you already know which chart you want), which is a reasonable implicit contrast to search_charts. However, no sibling is named and no condition is stated for choosing this over search_charts when only a title fragment is known. Usage 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?

The annotations already establish read-only, idempotent, non-destructive behavior, and the description adds meaningful context: it states what evidence supports each score, that atlas partners are split into confirmed and possible, that ADV assets are shown only when matched, and that Form D is a self-reported notice rather than a closed round. That last caveat is a useful warning that annotations cannot express and directly affects how the 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?

The core payload is front-loaded and the caveats land well at the end, but the first sentence is a long run-on built from stacked parentheticals and nested clauses that makes the scoring output harder to parse at a glance. A short bulleted breakdown of returned fields would carry the same information more cleanly.

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

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

There is no output schema, so the description carries the full burden of explaining return values, and it does so in detail: scores, evidence and reasoning, lever status, atlas partners, and ADV assets, plus the unclear bucket. The remaining gap is the rubric itself: what a 1 versus a 5 means is not defined, which leaves the agent dependent on the get_distribution_moat_score sibling to interpret scores.

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?

With 100% schema description coverage, the schema already documents all five parameters, including defaults, ranges, and regex. The description only reinforces two behaviors: an empty date returns the latest day, and unsettled filings surface as unclear, which relates to include_unclear. It adds no boundary conditions beyond that 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?

The description gives a concrete verb and resource: it returns every new SEC Form D notice from a single filing day, filtered to AI companies and scored 1-5 on the Distribution Moat rubric. That clearly separates it from the calc_* and chart/investor siblings. However, it never mentions get_new_raises, which appears to be the closest overlap, so the boundary between the two tools is left implicit.

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 context is implied by the 'daily read on AI private markets' framing, and two operational rules are stated: leave date empty for the latest day, and unclear filings are listed rather than guessed. There is no explicit when-to-use or when-not-to-use guidance relative to get_new_raises or get_distribution_moat_score.

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 bar is lower. The description adds real value beyond them: it discloses the scoring is a deterministic rule-based heuristic, that only listed channels and the data/network flag affect the result, and that business_model is inert and echoed back. It stops short of describing output structure or any scoring breakdown.

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 with the core definition front-loaded, followed by the echo caveat and the disclaimer. The disclaimers are load-bearing (they prevent misuse as an investment signal), so the length is justified, though the phrasing is slightly dense.

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 no-output-schema, 4-param tool with full schema coverage, the description covers the essential behavior: what is scored, what is inert, and what the result means. It could say more about the return shape (just the number, or a breakdown), but an agent has enough to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds a semantic layer the individual field docs don't: it clarifies which parameters actually move the score ('using only the acquisition channels you list and whether you have proprietary data or network effects') and that business_model is echoed rather than scored.

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 ('Rule-based 1 to 5 score of distribution defensibility') and pins down exactly which inputs drive it (acquisition channels plus the proprietary-data/network flag). This is clearly distinguishable from the calc_* financial siblings without opening any schema.

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

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

The negative scoping is useful ('not a valuation, not an investment decision and not a prediction', 'discussion aid'), which tells the agent when not to over-rely on it. However, there is no positive routing: it never says when to reach for this versus calc_fundraising_readiness or get_mode_vc_thesis_and_criteria, so usage 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.

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

The annotations already declare a safe read-only, idempotent operation, so the description does not need to restate safety. It adds useful behavior beyond annotations by defining confirmed/probable/possible tiers, explaining that weak matches are hidden by default, and noting the 'dataset not available yet' state.

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 front-loaded and compact: three sentences cover the return contents, match-tier semantics, and dataset availability without wasted words. Every sentence contributes operational meaning.

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

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

There is no output schema, but the description sufficiently enumerates what is returned and explains the key result-quality distinction. Annotations cover the safety profile, so nothing critical is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics for include_weak_matches by explaining which tiers are hidden and why. It also reinforces that firm is an Atlas slug or name, though the schema already documents that example.

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+resource: it returns SEC Form ADV records, Form D filings, and an activity roll-up for a firm in the Mode VC Investor Atlas. This is clearly distinguishable from sibling calculation and investor-search tools because it targets filings linked to a firm.

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 establishes the usage context clearly: the firm must be in the Mode VC Investor Atlas. It also explains that weak matches are hidden unless include_weak_matches is true, though it does not explicitly compare against alternatives such as get_investor_details or get_new_raises.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety bar is low. The description adds real behavioral detail beyond that: the 12-partner cap, that the total partner count is still returned, and which data domains are out of scope — meaningful because there is no output schema to disclose the return 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?

Two sentences, front-loaded with the action and return contents, with the limiting constraints (12 partners, no portfolio/theses) placed last where they belong. The field enumeration is dense but every item carries selection value.

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 full burden of describing return values and does so thoroughly, including caps and absences. Combined with 100%-covered parameters and read-only annotations, an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single parameter already carries a description with concrete slug/name examples. The description adds no lookup-format guidance (matching rules, ambiguity handling) beyond what the schema provides, 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 ('Returns one firm from the Investor Atlas') and then enumerates exactly what is returned: HQ/locations, links, latest fund, entry stages, check size bands, lead preference, sectors, partners. The closing exclusion of portfolio companies and investment theses implicitly separates it from get_mode_vc_thesis_and_criteria and from search_investors.

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 scope exclusions ('does not include portfolio companies or investment theses') hint that another tool covers theses, but neither sibling is named and no explicit when-to-use condition is stated. Usage is implied rather than directed.

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, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds meaningful non-annotation context: the data is published/firm-authored material sourced from a specific URL, implying a static snapshot rather than live deal data or personalized guidance. It does not state staleness or freshness guarantees.

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 verb and resource and then lists the returned content. No filler, no restatement of the title, nothing that fails to earn its place.

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

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

With no output schema, the description must carry the return-value burden, and it does so by enumerating the fields returned (ticket size, geography, stage, conviction, how to pitch). Combined with annotations covering safety and zero params, this is nearly complete; only freshness/staleness of the published data is left unstated.

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 (empty object, additionalProperties=false), so per the rubric the baseline is 4. There is nothing for the description to disambiguate on the input side, and it does not confuse the reader with any implied optional inputs.

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+resource: 'Returns Mode VC's published investment parameters' followed by an explicit enumeration of the payload (ticket size, geography focus, stage, core conviction, how to pitch). An agent can immediately tell this is a firm-level thesis lookup. It does not explicitly contrast itself with get_investor_details or search_investors, so it stops 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 — the mention of 'how to pitch' hints at the fundraising/pitch-prep scenario, but there is no explicit when-to-use, when-not-to-use, or alternative routing (e.g. 'use get_investor_details for other firms, this only covers Mode VC'). Adequate but leaves the agent to infer the trigger 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?

Beyond the readOnlyHint annotations, it explains the data source (public EDGAR), the semantics of a Form D (a notice filed after selling securities, not a funding announcement), that amounts are self-reported, and the exact failure string returned before Mode VC data loads. That is substantive behavioral context annotations cannot convey.

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

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

Front-loaded with the core action and returned fields, then two short clarifier sentences about Form D semantics and the data-availability caveat. Slightly dense first sentence but every sentence 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 compensates by enumerating the returned fields (issuer, amount sold, related persons, EDGAR link) and flagging the self-reported nature of amounts plus the not-yet-loaded state. An agent has everything needed to call and interpret results.

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 filters (limit, query, state, industry_group, min_amount_sold) are already documented in the schema. The description adds no per-parameter syntax or defaults, 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 ('Lists recent SEC Form D filings') plus scope qualifiers (venture funds and technology companies, last few filing days, public EDGAR data). An agent can distinguish it from get_firm_filings and the calc_* siblings without opening any schema.

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

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

It implies when the tool is appropriate (recent Form D activity) and gives a when-not caveat ('Returns

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds genuine context beyond that: the one-new-chart-per-day cadence, the topic mix (AI model, adoption, developer-package, pricing data), and the exact fields included per chart.

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 that front-loads the resource and recency, then packs cadence, ordering, scope and return fields without a wasted word.

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 no-required-parameter read tool with no output schema, the description covers what the tool returns and how results are ordered, which is the essential missing structured information. It does not mention pagination beyond the limit or error/empty-archive behavior, but little else is needed.

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 the single limit parameter is fully documented in the schema, including its default of 3 and 1-10 bounds. The description adds no additional meaning about the parameter, 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?

The description names a specific verb and resource (returns the most recent charts from the Mode VC Chart of the Day archive), states ordering (newest first), and enumerates returned fields (claim, takeaway, URL, sources). It implicitly separates itself from search_charts by emphasizing recency rather than querying, but never names a sibling explicitly.

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 'most recent charts' and the default limit of 3, so an agent can infer this is the browse-latest entry point. However, there is no explicit statement of when to prefer this over get_chart_data or search_charts, and no 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuine context beyond them: what the result contains (claims, takeaways, canonical URLs, markdown endpoints, cited sources) and that the archive grows daily with the response reporting its current size.

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 compact sentences, front-loaded with the action and scope, then return contents, then freshness. No filler and nothing repeated from the structured fields.

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 read-only search tool with no output schema, the description covers scope, matching fields, returned artifacts, and data freshness. An agent has everything needed to call it and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description earns a bump by clarifying what the free-text query actually matches against (title, claim, takeaway, keywords), which the schema alone does not say. The limit parameter is left entirely to 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 (Searches) and resource (every chart in the Mode VC Chart of the Day archive) plus the exact fields matched (title, claim, takeaway, keywords). The read/search framing implicitly separates it from the get_* siblings, but no sibling is named explicitly, so it stops 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 implied: reach for this when you want to find charts by keyword rather than fetch a known one. However, it never says when to prefer it over get_chart_data or get_venture_chart_of_the_day, and there are no stated 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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely non-structured context: data provenance ('compiled from public information'), that counts appear in the response, and that stage/check size are self-reported and may be unavailable. No contradictions.

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 compact sentences: purpose first, filters second, caveats last. Every clause carries information, and the parenthetical about counts is short. Slightly dense in the middle sentence but appropriately sized with no filler.

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 necessary work: it names the data source, the filterable dimensions, the reliability caveat on self-reported fields, and notes that counts are returned. What is still missing is a hint at the shape of a result record (fields returned per firm/partner), which would help an agent chain into get_investor_details.

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 every parameter is already documented with examples and enums; the baseline is 3. The description's sentence 'Filter by firm or partner name, sector, entry stage, and headquarters or location' largely restates the schema, adding only the caveat that stage and check size are as reported by each firm.

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 ('Searches the Mode VC Investor Atlas') and immediately defines scope: a directory of VC firms and their partners compiled from public info. It also draws negative boundaries ('does not hold portfolio companies or fund performance'), which lets an agent distinguish this from get_investor_details and the thesis tool at a glance.

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 enumerates the filter dimensions, which implies how to narrow a search, but never states when to choose this tool over the sibling get_investor_details or get_mode_vc_thesis_and_criteria, nor any recommended sequence (search first, then fetch details). Usage is implied rather than guided.

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