Search and retrieve time-series data across 38 empirical AI adoption and venture research charts.
Scored across 3 tools
Each tool has a distinct retrieval mode: single chart by slug/title (get_chart_data), newest-first recency list (get_venture_chart_of_the_day), and keyword search (search_charts). The overlap is mild since all three return chart claims/takeaways, but the lookup mechanics differ enough to guide selection.
Two tools follow a get_<object> verb_noun pattern and the third uses search_<object>, which is a readable and predictable convention. The only deviation is the verbose get_venture_chart_of_the_day, which is longer than its siblings but still interpretable.
Three tools is thin for an archive that grows daily and exposes multiple access patterns (lookup, recency, search). It covers the core read paths but leaves no room for listing, pagination, or date-range browsing.
Core retrieval (lookup, search, recent) is covered, but there is no way to enumerate or paginate the full archive or filter by date/category. Agents needing a complete sweep of the chart history would hit a dead end.
Returns one chart from the Chart of the Day archive: the data table behind it (rows as published), claim, takeaway, note and the sources it cites. Look up by slug or title. Data is as published on the chart page; follow source_urls for the original data.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Chart slug or title, e.g. "pre-seed-valuation-dispersion", "ai-inference-cost-comparison" |
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.
Returns the most recent charts from Mode VC's Chart of the Day archive (one new chart per day, mostly AI model, adoption, developer-package and pricing data), newest first, each with its claim, takeaway, URL and cited sources.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of recent charts. Default 3. |
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.
Searches every chart in the Mode VC Chart of the Day archive by keyword over title, claim, takeaway and keywords. Returns claims, takeaways, canonical URLs, markdown endpoints and cited sources. The archive grows by one chart a day; the response states its current size.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum charts to return. Default 10. | |
| query | No | Search term, e.g. "pricing", "claude", "inference", "sdk" |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_chart_data1 field changedInput schema / properties / slug / descriptionPrevious value: -"Chart slug or identifier (e.g. \"pre-seed-valuation-dispersion\", \"ai-inference-cost-comparison\", \"open-source-vs-closed-ai-models-gap\")"New value: +"Chart slug or title, e.g. \"pre-seed-valuation-dispersion\", \"ai-inference-cost-comparison\""get_venture_chart_of_the_day2 fields changedInput schema / properties / limit / defaultRemoved value: -3Input schema / properties / limit / descriptionPrevious value: -"Number of recent charts to retrieve"New value: +"Number of recent charts. Default 3."search_charts4 fields changedInput schema / properties / limit / defaultRemoved value: -10Input schema / properties / limit / descriptionPrevious value: -"Maximum number of charts to return"New value: +"Maximum charts to return. Default 10."Input schema / properties / limit / maximumPrevious value: -38New value: +100Input schema / properties / query / descriptionPrevious value: -"Search term matching title, claim, key takeaway, or keywords (e.g. \"pre-seed\", \"pricing\", \"claude\", \"inference\", \"sdk\")"New value: +"Search term, e.g. \"pricing\", \"claude\", \"inference\", \"sdk\""get_chart_dataget_venture_chart_of_the_daysearch_chartsQuery 38 empirical AI market charts, evaluate distribution defensibility, and search 3,650+ VCs.
Query empirical frontier LLM release velocity, inference token deflation, and enterprise AI spend.
Read-only AI impact metrics with search, methodology and cited sources. No authentication required.
Funding rounds, AI startup and investor search, email discovery, agent-readiness. No API key.
Add one secure layer between your agents and this server.
