TubeSaku Creator Insights

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

Annotations already establish a safe, idempotent, closed-world read, so the description rightly spends its space on output behavior: missing metrics are omitted and their reasons aggregated in quality.missing_fields with row pointers in series_indexes, latest_available_period marks the stored newest week, is_latest_period flags rows, and period_label_only signals an unknown observation date. That is meaningful context an agent cannot get from annotations, though the per-row field set is still only partially described.

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 purpose is front-loaded in the first sentence and no sentence is pure filler. However, it is one dense run-on block that interleaves parameter rules, ranking semantics, and output-field explanations, making it harder to scan than a partitioned structure would be.

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 four parameters, no output schema, and a fairly rich return shape, the description does substantial work: it covers ranking comparison, horizon and row limits, fuzzy name matching, missing-data handling, and week-identification fields. It falls short of fully specifying the returned metric fields and what distinguishes Steam player counts from YouTube view counts beyond noting that they are separate metrics.

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 carry the load, and it largely does: it details game matching (Japanese/English names, fuzzy partial match with case, width, space, symbol and kana normalization, 1-character edit tolerance for English words of 4+ letters), the 4-week `weeks` cap, the 10-row `limit` cap, and the u10k default for `segment`. The gap is that valid `segment` values other than the default are never enumerated, and the caps are stated as return limits rather than parameter semantics.

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 opening sentence names a specific resource and operation: a weekly comparison of per-game demand rank and supply rank, top-10 ranking, up to 4 weeks back, max 10 rows returned newest-week-first. The subject matter (game demand/supply) is clearly distinct from the VTuber/streaming siblings, though no sibling is named explicitly to sharpen the boundary.

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 rather than stated: the agent can infer this is the tool for comparing game demand vs supply rankings, and hard constraints (max 4 weeks, max 10 rows, default segment under 10k subscribers) are given. There is no explicit when-to-use/when-not-to-use guidance and no pointer to an alternative sibling tool for related queries.

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 that this is a safe, read-only, idempotent, non-destructive operation. The description adds that output includes observation timestamps and missing-information context, but does not describe return format, pagination, or other operational traits beyond 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 short sentences with no filler. The catalog scope is front-loaded, followed by the additional observation/missingness 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?

For a no-argument catalog tool, the description covers the key content an agent needs to know it returns: free-data listing, update times, observation range, missingness/staleness, usage conditions, and observation timestamps. It is reasonably complete, though it could say more about output structure since 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?

The tool has zero parameters, which is the baseline for a 4. There are no parameter semantics to clarify, and the description correctly does not pretend otherwise.

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 clearly states the resource (free data catalog) and the specific information it exposes: update timestamps, observation range, missingness, staleness, and usage conditions. It does not explicitly differentiate itself from sibling tools such as get_tubesaku_index or read_tubesaku_markdown, 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 the stated purpose: use this when you need a catalog of free data with freshness, missingness, and usage-condition metadata. There is no explicit when-to-use/when-not guidance or comparison to sibling tools such as search_tubesaku_context.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful context—that the source is llms.txt and that results are capped at 10—but says nothing about ordering, completeness, pagination, or what happens when no entries exist.

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 short sentence with the source and the result cap front-loaded. No filler or redundant restatement of the tool title.

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

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

With zero parameters, rich read-only annotations, and no output schema, the description covers the essentials of what the tool does. However, for a discovery tool it does not clarify whether the returned list is exhaustive, how entries are ordered, or whether the 10-item cap means callers may miss documents.

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 no parameters, so there is no parameter semantics burden and the baseline of 4 applies. The description correctly does not invent or discuss 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?

States a specific action and resource: reads TubeSaku's llms.txt and returns a list of available public Markdown documents, capped at 10. It is clear enough to distinguish from read_tubesaku_markdown, but it does not explicitly differentiate itself from get_tubesaku_data_catalog.

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 this is a discovery/index tool but never says when to use it versus get_tubesaku_data_catalog, read_tubesaku_markdown, or search_tubesaku_context. 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 declare readOnly, idempotent, closed-world, non-destructive behavior, so safety is covered structurally. The description adds some content context (limits, availability, Coming Soon tiers, inclusion of fact information for individual analysis), but the '個別分析の事実情報' clause is vague and nothing is said about output size or shape for a tool with 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 short sentences, front-loaded with the primary return content before the Coming Soon caveat. No filler, though the final clause about individual-analysis facts is loosely attached and slightly muddies the topic.

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 what comes back, and it only sketches categories rather than the structure or granularity of the response. For a simple zero-param info tool this is adequate but leaves the agent guessing about the actual payload.

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 there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies a parameterless call and does not waste space restating the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description names a concrete return payload — MCP usage conditions, retrieval limits, and availability status — plus a note about which service tiers are Coming Soon. It is clear what the tool returns, but it never contrasts itself with the sibling data tools (search_tubesaku_context, get_tubesaku_data_catalog), so the boundary is only implied by the word 'info'.

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 can infer it should call this to learn limits or availability, but there is no explicit 'call this before/after X' or exclusion guidance. No alternative sibling is named for the case where the agent actually wants data rather than terms.

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, non-destructive and closed-world, so the safety profile is covered. The description adds that content lives under the llms.txt publication path, which is useful context, but says nothing about error behavior for missing paths or what the returned Markdown looks like.

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 lines, front-loaded with the purpose followed by a concrete path example. No filler, though the wording is terse enough that a little more guidance could have been added without bloat.

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 tool with strong annotations and no output schema, the core is present, but the agent still lacks the discovery workflow (where do valid paths come from?) and any description of the returned content or failure modes.

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 carries the burden for the single 'path' parameter. The example '/llms/google_trends.md' usefully conveys the expected format and prefix, but it does not state whether other prefixes exist or whether the path is relative, nor enumerate valid values.

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 ('読む'/read) and a specific resource (TubeSaku Markdown files published via llms.txt). It implicitly distinguishes itself from catalog/index/search siblings by being a direct file read, though it never names those siblings 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?

No statement of when to use this tool versus get_tubesaku_index, get_tubesaku_data_catalog, or search_tubesaku_context, and no prerequisite that a path must first be discovered through the catalog/index. The agent must infer the workflow.

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 two genuinely new facts — a hard cap of 5 results and a licensing caveat that the agent should surface to the user — but says nothing about result shape, ranking stability, or what happens when fewer than the cap match.

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 short sentences, front-loaded with purpose then constraints; nothing is padded. It is slightly under-specified rather than verbose, so brevity here is more a symptom of missing detail than of tight writing.

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 should compensate more than it does, and two of four parameters go unaddressed. It does cover the ranking basis and the licensing caution, which are the highest-value context for this tool, making it 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 carries the full burden. It only lists the legal scope strings (without defining any of them) and implies the limit cap via '最大5曲'; keyword and require_playlist_video receive no mention at all, and the scope semantics an agent would need to choose correctly are absent.

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 (search cover-song candidates) plus the ranking signals used (original-song popularity, recent competitor count, 6-hour-engagement proxy). An agent knows exactly what the tool returns candidates for, though it does not distinguish itself from any sibling — no sibling is close enough to require 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?

The scope enumeration implies different search modes, but the description never explains what each mode means or when to pick one over another, and no alternative tool is mentioned. Usage is implied rather than guided, and the default (low_supply) is left unstated in the text.

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 the description adds real value beyond them: a 2-hour observation window and the warning that streams ending immediately before the query may be unconfirmed. It stops short of describing result ordering or volume, but the staleness disclosure is exactly the kind of behavior an agent needs and cannot get from 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?

The description is dense and front-loaded with the purpose before the parameter clauses, and every clause contributes information. It reads as a run of telegraphic fragments without visual separation between purpose, params, and caveats, which slightly slows parsing.

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 3-parameter, all-optional search with annotations but no output schema, the definition covers scope, all parameter semantics, and freshness limits. The remaining gaps are the return shape (no output schema exists) and sibling differentiation against search_live_streams.

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 carries the full burden and does: keyword is a partial match across title/channel/description capped at 200 chars, category is a YouTube category ID with a concrete example (20=ゲーム), and limit is constrained to 1–10 with default 5. All three parameters get meaning the bare schema does not provide.

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 phrase "最終確認時点で配信中のライブを検索" gives a specific verb (検索) plus resource (配信中のライブ) with a temporal qualifier, so the agent knows this returns currently-active streams only. It never mentions the sibling search_live_streams or explains how the two differ, so the agent must infer the distinction from the name alone.

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 explicit when-to-use/when-not-to-use guidance and no named alternative among the nine siblings. Usage is only implied through the freshness caveats ("2時間以内の観測のみ", "検索直前の終了は未確認"), which tell the agent when the data is trustworthy but not why to pick this tool over search_live_streams.

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), and the description adds real value on top: a 7-day window, a 10-item preview cap, grace-period expiry semantics, and the fact that a total-match count is returned alongside results. The unstated interaction between the '10 items' cap and the 'limit' parameter is the one ambiguity left.

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?

Information-dense and front-loaded: the search dimensions come first, then the constraints on scope. Every sentence carries a distinct constraint, though the compact clause style makes a few rules (grace period, the 10-item cap) harder to parse than they need to be.

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 tool with no output schema and no schema descriptions, the definition covers scope and result-count but leaves the keyword/limit semantics and all input formats unstated. An agent can guess most calls correctly, but cannot be certain about date formatting or what the free-preview cap does to a larger limit.

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 8 parameters, so the description must carry the load. It does map most filters to meaning (JST dates, start/end time slot, debut_only as '初配信候補', category as 'ジャンル'), but says nothing about 'keyword' or 'limit', and gives no date/string formats for the six string parameters.

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 opens with a specific verb+resource ('search scheduled live streams') and enumerates the filter dimensions (JST date, time slot, debut candidates, genre). It implicitly separates itself from search_current_live_streams by stating '現行予告のみ' (current notices only), but never names that sibling explicitly, so differentiation requires 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?

Strong exclusion guidance: past debut notices and ended-stream history are unavailable, and notices past their start time drop out after a grace period. It also states the free-preview caps (7 days / 10 items). What's missing is an explicit pointer to which sibling to use when the agent wants currently-live streams or historical data.

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, idempotentHint=true and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the matching is a simple whitespace-delimited token search rather than semantic, and results are excerpts of likely-relevant body text rather than structured records. Result-count limits and ranking are still undisclosed.

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 the purpose front-loaded and the query constraints second. Nothing is repeated from the schema and nothing is 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?

For a one-parameter read tool without an output schema, the description covers the input side well and states that body text is returned. It leaves open what a result actually contains — whether source document names or URLs accompany the excerpts, how many hits come back, and whether there is ranking — which an agent needs in order to chain a follow-up read_tubesaku_markdown call.

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 carries the full burden and does well: it states the query is split on whitespace, must be 1–500 characters and 1–20 words, and that duplicate terms are dropped. This is exactly the constraint information an agent needs to form a valid query, though it doesn't clarify case sensitivity or whether multi-word terms are ever treated as phrases.

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: a cross-cutting read over TubeSaku's public Markdown that returns body text matching the query. That clearly separates it from read_tubesaku_markdown and get_tubesaku_index, though those siblings are not named explicitly, so the differentiation is inferred rather than stated.

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

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

'横断的に読み' (read across documents) implies this is the tool to use when you don't know which document holds the answer, as opposed to reading a specific file. However, there is no explicit when-to-use, no exclusions, and no mention of what to do if results are sparse or if a direct read would be better.

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, so the safety profile is covered. The description adds real behavioral context beyond that: some VTubers lack profile text, and a missing game entry does not mean the game was not played — both cautions directly affect how results should be interpreted.

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 filter semantics are front-loaded and every clause carries information; nothing is filler. It is a single dense run-on block with heavy parenthetical stacking, which slightly hurts scannability but not accuracy.

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, fully optional filter tool with no output schema, the description covers every input and the interpretive caveats an agent needs. It stops short of describing the result shape or ordering, which would be useful without an output schema, but nothing required to call 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 description coverage is 0%, so the description carries the full burden, and it does: debut_year bounded 2000–2100, dates as YYYY-MM-DD with inclusive endpoints, game matching rules (ID / Japanese / English names, fuzzy substring, case/width/whitespace/symbol/kana normalization, 1-edit tolerance on English words of 4+ chars), keyword partial match with a 200-character cap, and limit 1–10. This is far more than the bare schema provides.

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 (収録VTuberを…AND検索) plus the exact filter dimensions — debut year, date range, game, keyword — so the agent knows precisely what this retrieves. It is clearly distinguishable from siblings like search_cover_songs or search_live_streams, which target different resources.

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 how filters combine (AND) and when a filter would silently return nothing (games not catalogued, missing profiles), but it never names an alternative tool or states an explicit when-to-use/when-not-to-use condition. Usage is implied rather than prescribed.

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