CodeNate-こうでねーと-

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

The annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the description does not have to restate the safety profile. It does add useful behavioral context: the tool returns the FULL text ('全文'), accepts a search-result id, a URL, or a path, and tolerates Japanese characters. It stays silent on truncation or size limits for very large pages, which is a minor gap.

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 three compact sentences: what it returns, how to supply 'id', and when to call it, with the core purpose front-loaded. The parenthetical site-name gloss ('CodeNate-こうでねーと-' / codenate.jp) is slightly decorative, but everything else earns its place.

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

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

The tool has one required parameter and an output schema, so the return format needs no explanation here. The description covers purpose, input flexibility, and the accuracy-verification use case. Only the lack of sibling differentiation against get_page keeps it from being fully complete.

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

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

Schema coverage is 100%, so the single 'id' parameter is already fully documented in the schema. The description largely repeats that (id = search-result id, URL, or path, Japanese allowed) rather than adding new meaning, so it earns the baseline 3 for high-coverage schemas.

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 ('読み込んだページの本文を全文返します'), which is clear enough that an agent knows it retrieves the body text of a page on codenate.jp. The gap is that it never distinguishes itself from the close siblings 'get_page' and 'search_pages': an agent cannot tell from the description whether 'fetch' and 'get_page' do the same thing.

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 gives a concrete trigger: whenever accuracy matters (prices, dates, conditions, terms), you should verify the body text with this tool before answering. It also explains that results from a 'search' can be passed in via their id. It stops short of stating when NOT to use this tool or which sibling to pick instead.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds a genuinely useful trait beyond them: the return shape differs from `fetch`, which matters for callers parsing the result. It stops short of saying what that shape actually is.

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 that each carry content (deprecation status, behavior, alternative), but the opening sentence about the legacy product name is largely historical context that a new caller gains little from. Front-loading the 'use fetch instead' guidance would serve the agent better.

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, and the description only says the returned shape "is different" from `fetch` without describing it, leaving the actual response format undocumented. Adequate for a deprecated shim whose users are told to migrate, but not complete on the one thing distinguishing it.

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% for the single `url` parameter, including the note that paths and Japanese characters are accepted. The description adds nothing about the parameter, so the baseline of 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 the action plainly ("fetch と同じようにページの本文を返します") and identifies it as a legacy alias of the codenate.jp feature, distinguishing it from the sibling `fetch` by noting the return shape differs. The framing leads with deprecation/identity rather than the verb+resource, so it is clear but not maximally direct.

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?

Explicitly names the alternative and the condition selecting it: retained only for users already connected under the old name, and "新しく使うときは fetch を使ってください" tells new callers to use `fetch` instead. No inference required about when to choose this vs. a sibling.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false. The description adds value beyond them by disclosing pagination behavior (50 per batch, max 200 via limit, continuation via offset) and the shape of the returned data.

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 returned, then pagination, then usage. Slight redundancy between the title ('どんなページがあるか見る') and the final sentence, but no wasted text.

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 listing tool with only two optional parameters and no output schema, the description covers return fields, pagination, and use conditions adequately. Only a total-count or ordering note 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 0%, so the description carries the burden, and it does: it explains limit's ceiling of 200 and default batch size of 50, and that offset fetches the continuation. It stops short of stating offset's default or unit semantics precisely, but compensation is strong.

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 (return a list) and resource (pages loaded in codenate.jp), and specifies the returned fields (title and URL). It does not name a sibling outright, but 'when you can't find something by searching' implicitly distinguishes it from search_pages.

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 two concrete use conditions: wanting to know what pages exist, and failing to find something via search. The alternative (search_pages) is implied rather than named, so it falls short of fully explicit routing but gives clear 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, destructiveHint=false and openWorldHint=false, so the safety profile is covered; the description complements that by disclosing the real limits an agent would otherwise hit (a fixed snapshot of already-loaded pages, with neither the wider web nor post-load updates visible). It also reveals fallback behavior: when nothing matches it returns candidate pages, and the agent is told not to guess beyond that. It stops short of describing result ordering, pagination, or hit counts.

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 purpose and scope are front-loaded in the first two sentences, and the remaining sentences each carry actionable instructions for the retry and miss path. It is somewhat long for a one-parameter search tool, but no sentence is filler: even the closing instruction against guessing changes how the agent responds to an empty result.

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?

The definition covers what the agent must know beyond the structured fields: the data boundary (loaded pages only), how to retry, and how to handle a no-match. The output schema means the description needs no explanation of return values, and the annotations mean it needs no safety caveats. Only the relationship to the sibling tools is left unaddressed.

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 'query' parameter already ships its own description and example, so the schema does the heavy lifting. The description adds only indirect hints about how queries are matched: it advises rephrasing the query with expanded abbreviations or synonyms, which implies plain keyword matching rather than operators or structured filters. Since there is only one parameter, that is close to the baseline.

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

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

The description gives a concrete verb and resource: it searches the text of pages previously loaded from codenate.jp and returns matching passages with excerpts and URLs. The scope is precisely bounded (loaded pages only, not the broader web). However, it never distinguishes itself from the sibling tool 'search_pages', which by name sounds like it does the same thing, so an agent cannot rule that sibling out without opening both 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?

It states explicitly when to reach for this tool (questions about CodeNate-こうでねーと- should start here), what it cannot cover (the open web, content updated after loading), and even prescribes a retry strategy: rephrase using expanded abbreviations or synonyms, then read the candidate pages returned on a miss before admitting the answer was not found. The only gap is that it never names the alternative sibling tools it should be preferred over or deferred to.

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

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

Annotations already declare read-only, non-destructive, closed-world behavior. The description adds important behavioral context beyond the annotations: it is a legacy/compatibility tool and its return shape differs from `search`, though it does not specify what that shape is.

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 legacy status, then behavior, then the recommendation to use `search`. There is little waste, though the title and description repeat the old-name framing.

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 legacy tool with no output schema, the description notes that the return shape differs from `search` but never describes what it actually returns. That is enough to steer new callers away, but incomplete for existing callers who still need to invoke 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 only 50%, and the description adds no parameter meaning at all. It does not explain how `query` should be formed or what `limit` controls, leaving the undocumented `limit` parameter to rely solely on its schema constraints.

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 that it searches within the site, that it is the legacy name of a feature, and that its return shape differs from `search`. This is specific enough to distinguish it from the sibling `search`, though it does not explicitly say it returns pages.

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?

Explicitly says to use `search` for new usage and that this tool is kept only for people already connected to it. This gives clear when-to-use and when-not-to-use guidance with a named alternative.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine value by enumerating the returned fields (type, introduction, loaded page count, main pages), which matters because there is no output schema. It does not state whether the overview reflects a live crawl or a cached index snapshot, which is the remaining gap.

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 with zero waste: the return content is stated first, then the field breakdown, then the usage trigger. Everything is front-loaded and each sentence carries distinct 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 parameters, no output schema, and annotations covering the safety profile, the description carries the burden of explaining return values and does so adequately. It stops short of clarifying data freshness or whether the site must be preloaded before an overview is available.

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

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

The tool takes zero parameters, so the baseline of 4 applies and there is nothing to document. The description does not need to compensate for any schema gaps.

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 resource (the codenate.jp site) and states precisely what is returned: site type, introduction text, number of loaded pages, and main pages. This clearly separates it from siblings like list_pages or search, which operate on individual pages rather than the site as a whole. It does not explicitly name a sibling, so a 4 rather than 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?

It gives a clear usage condition: use it first when you want to grasp the overall picture of the site (「最初にサイトの全体像をつかみたいときに使います」). There are no explicit exclusions or named alternatives, but the 'first' framing implies an orientation step before fetch/get_page/search.

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