GlobalPiggy

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 behavior is fully covered elsewhere. The description's added value is telling the agent what the returned record contains (aim, idea, tip), which matters because no output schema exists. It says nothing about error behavior for an unknown id or about the lang parameter's effect.

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, front-loaded with what the tool returns and followed by the prerequisite. No filler or repetition of the 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?

For a two-parameter, read-only lookup with full schema coverage and complete annotations, the description supplies the one thing structured data lacks — the shape of the returned content. Only the failure mode for an invalid id is 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%: id's provenance and example (applied_safety_01) and lang's allowed values are already documented in the schema, and the description only echoes the id source. Baseline 3 applies since the schema does all parameter work.

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

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

The description names the resource (a single BillyGo practice pattern) and enumerates its contents — goal, underlying idea, and coaching tip — which clearly separates it from billygo_list_patterns. It never uses an explicit retrieval verb, but the content inventory makes the operation unambiguous.

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?

"Get ids from billygo_list_patterns" gives an explicit prerequisite and points at the sibling that supplies the required id, effectively routing the agent. It does not state when-not-to-use (e.g. listing all patterns), but for a trivial by-id lookup that omission is minor.

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 safety needs no restating. The description adds the useful behavioral fact that this is a lightweight summary endpoint and detail lives elsewhere. It says nothing about pagination, result count, or whether an empty result set is possible when filters match nothing.

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, no filler, with the returned fields listed compactly and the cross-reference to the detail tool placed last. The colon-and-enumeration structure is easy to parse. Minor wasted lead-in on 'BillyGo's carom billiards practice patterns' before the useful content.

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 shoulders the burden of describing returns and does so by naming every field. It covers the sibling relationship and the three optional filters are fully documented in the schema. Only pagination and empty-result behavior are absent, which is a small gap for a simple read-only list.

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%; lang, category, and difficulty all carry descriptions with examples, and the description only echoes the category examples already in the schema. No additional semantics such as filter combination behavior or whether unknown values error out. 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?

The description states the resource (carom billiards practice patterns) and enumerates the fields each entry carries (id, title, subtitle, category, difficulty), so an agent knows exactly what a call yields. It is distinguishable from billygo_get_pattern, which is named as the detail fetch. It stops short of a crisp verb like 'list' in the description itself, relying on the name/title for that.

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 routes the agent: use this to see pattern summaries, use billygo_get_pattern for the goal, idea, and coaching tip. That is a clear this-vs-alternative split. It gives no guidance on when not to use it or on combining filters, 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 declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuine value beyond that by disclosing the shape of the return payload (paragraphs or markdown, tips, source note). It does not mention article length, truncation, or missing-slug behavior, which keeps it below a 5.

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 payload description and ending with the prerequisite. No filler, no repetition of the title or annotations.

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 two-parameter read tool with no output schema, the description covers what comes back and where the required slug originates. The lang parameter's fallback behavior is handled in the schema, so the only remaining gap is edge-case behavior (unknown slug, very long articles), which is minor.

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 schema fully documents both slug (with an example) and lang (allowed values and the English fallback). The description adds only the provenance hint for slug, which the schema already states, so the schema does the heavy lifting and 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+resource: returns the full text of one FreshCheck article, and names what the payload contains (paragraphs or markdown, practical tips, source note). It also names the sibling that supplies the required identifier, so the agent can distinguish it from freshcheck_list_articles 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 closing sentence explicitly routes the agent: get slugs from freshcheck_list_articles, which establishes the correct call order and the alternative for browsing. There is no explicit 'do not use when' clause, but for a simple single-item read the implied usage is unambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is fully covered elsewhere. With no output schema, the description's field list (slug, title, topic, excerpt, tags) is the only disclosure of what the call returns, which is genuinely useful. It says nothing about result volume, ordering, or pagination behavior for a list endpoint, leaving that gap unaddressed.

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 plus a short routing clause, with the resource and return fields front-loaded and nothing redundant. Every clause carries information: subject matter, record fields, and the follow-up tool.

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 two-optional-parameter list tool with no output schema, the description covers what the tool returns and how to follow up with a single-article fetch. The language fallback behavior and pillar filter are handled by the schema, so the remaining omission is pagination or result-size expectations. That is a minor gap rather than a blocking one.

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 both lang and pillar documented in the schema itself, so the baseline is 3. The description adds only the parenthetical 'topic (pillar)', which maps the pillar filter to the conceptual topic field, and the subject-matter examples that hint at valid pillar values. That is marginal added meaning rather than substantive compensation.

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

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

The description names the resource (FreshCheck short articles) and enumerates its subject matter and the fields each record carries (slug, title, topic/pillar, excerpt, tags), so an agent knows exactly what comes back. It clearly separates itself from freshcheck_get_article by pointing at it for single-item reads. It does not explicitly distinguish itself from freshcheck_list_produce, which overlaps conceptually with the 'choosing produce' content mentioned here.

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 closing sentence 'Read one with freshcheck_get_article' gives explicit routing to the sibling tool for single-article retrieval, which is the main alternative an agent would consider. There is no explicit 'when not to use' statement or guidance on whether this is a browse-all call versus a filtered search, but the usage context is clear enough to act on.

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 needs no restating. The description adds genuinely useful context the annotations do not carry: the data provenance (USDA FoodData Central), the per-100 g basis, and the presence of a plain-language summary and serving ideas in the payload. It stops short of describing result shape or how many profiles come back.

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?

Effectively one front-loaded sentence plus a short disclaimer; nothing is repeated and the nutrient list is informative about output. The enumeration is long but each item earns its place as a returned-field disclosure in the absence of an output schema.

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 return-value burden and does it reasonably well by naming the nutrients, the per-100 g unit, the source, and the accompanying summary and serving ideas. The gaps are behavioral rather than content-level: whether an unfiltered call returns everything, and how results are ordered or limited.

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 schema already documents lang (with its six allowed values and English fallback) and query (partial name or id, with examples). The description adds nothing about either 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 the resource precisely (nutrition profiles for common fruit and vegetables FreshCheck knows) and enumerates the fields returned, so an agent knows exactly what data it gets. It does not explicitly say it returns a *list* keyed by the optional query, nor differentiate itself from freshcheck_list_articles / freshcheck_get_article, but the resource is unmistakable.

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 guidance on when to call this versus the article tools, nor on how the optional query and lang parameters should be used (all-produce listing vs. name lookup). The only usage signal is the scope caveat 'General information, not dietary advice', which constrains framing rather than invocation.

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 useful context beyond that: the response shape (id, localized title, emoji) and the privacy rationale explaining why listing data is withheld. It says nothing about ordering or stability of the category set, so a 3 rather than a 4.

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, front-loaded with what the tool returns before the exclusion. No filler, though the enumeration of five category names is slightly verbose relative to the rest.

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-optional-parameter, no-output-schema lookup tool this covers purpose, return fields and scope limits adequately. Minor gaps (order of returned categories, whether the list is fixed) are not material to calling 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 schema already documents the lang parameter with allowed values and the en default. The description only adds that the language affects the returned titles, a minor elaboration over 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?

The description names the specific resource (the five listing categories in IutGotGan) and enumerates them — producer sales, direct trade, swap/barter, garage sales, free giveaways — plus the returned fields. It also explicitly scopes out individual listings, so an agent knows this is a category-enumeration tool, not a listing search.

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 clear context — call this to obtain category ids/titles, and note that individual listings are not obtainable here for privacy reasons. There is no explicit statement of prerequisites or a named alternative for fetching actual listings, which keeps it 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 declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile needs no restating. The description contributes one genuine behavioral detail — that coverage is limited to countries 'JumunCheck covers' — but says nothing about language fallback, coverage gaps, or data freshness beyond what the schema states.

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 with no filler, and the country-facet framing leads. The long comma-delimited field list is dense but each item conveys a distinct returned attribute, so little could be cut without losing routing 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?

For a simple two-parameter read-only reference lookup with no output schema, the description does the necessary work of telling the agent what fields the response will contain. It is effectively complete for invocation; only inter-sibling differentiation against jumuncheck_get_guide 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%, so both params (lang, country) are fully documented, including the omit-for-all-countries behavior and the English fallback. The description adds no parameter-level meaning beyond the schema, 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 enumerates the exact content the tool returns (currency, sales tax inclusion, service charge, cover charge, tipping, tap water, drinking age, portions, visitor tips), which clearly separates it from jumuncheck_list_dishes and jumuncheck_list_places. It is phrased as a content inventory rather than an action ('How a restaurant bill works...'), so the verb is only implied by the name/title, keeping it 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 subject matter: an agent can infer this is the reference to consult for country-level bill etiquette. There is no explicit when-to-use framing, no mention of how this differs from the sibling jumuncheck_get_guide, and no statement about the no-country case (that exists only in the schema).

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 contributes beyond that by previewing the response contents (etiquette, phrases in English/local script/romanization, covered cities, dish ids), which tells the agent what it will actually get back from a call.

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, front-loaded with the core purpose and then a compact content inventory. Every clause conveys real information about the payload; there is no boilerplate or repetition of the name/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 no output schema, the description carries the burden of describing returns and does so thoroughly, and the annotations cover the safety profile. Only minor gaps remain (error behavior for unknown or unsupported country codes), which an agent could infer but would prefer to see stated.

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%: the country code format/example and the lang enum with its English fallback are fully documented in the schema. The description adds nothing about parameters, so the baseline 3 applies — the schema does all the work.

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 ("a short dining guide for one country") and then enumerates exactly what the guide contains: etiquette, ordering/paying, phrases, cities, dish ids. It is clearly distinguishable from jumuncheck_get_country_rules and jumuncheck_list_dishes, the latter of which it explicitly names.

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 parenthetical "see jumuncheck_list_dishes" routes the agent to the sibling for dish-level detail, implying this tool is the country-level overview. There is no explicit when-not-use guidance versus jumuncheck_get_country_rules or jumuncheck_list_places, so it stops short of full routing.

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 establish read-only, idempotent, non-destructive behavior, so the description's job is to add context — which it does by disclosing the exact field set returned (taste levels 0–3, risk flags for raw/offal/alcohol/bones/shared plates) and the important limitation that allergen and diet data describe only the typical recipe. That limitation is genuine behavioral context not captured by 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?

Two sentences, front-loaded with the resource and scope, followed by the safety caveat. The long field enumeration is dense but each item conveys real information about the payload; nothing is redundant with the 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 no output schema, the description carries the burden of explaining return values and does so thoroughly, including risk flags and taste scale. Only minor gaps remain — no mention of result volume, pagination, or behavior on empty matches — which are low-risk for a read-only dictionary lookup.

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 each parameter is already well documented in the schema, including the language fallback and ISO code format. The description only lightly reinforces parameter meaning ('name in the requested language and locally'), 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?

Names a specific resource (JumunCheck's dish dictionary) scoped to one country, and enumerates the content returned. It is clearly distinguishable from jumuncheck_get_country_rules and jumuncheck_list_places by resource type, though it does not explicitly contrast itself with them.

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 'dish dictionary for one country' and the query/lang parameters, and it gives downstream guidance ('always tell the person to confirm with the restaurant'). However, it never states when to choose this over siblings like jumuncheck_get_country_rules or jumuncheck_get_guide, leaving routing to inference.

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 behavior, so the description's added value is the coverage caveat: the list is small and hand-picked, and details can be out of date. That is genuine behavioral context an agent needs before trusting results. It stops short of stating how many results to expect or whether results are ordered.

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 front-loaded sentence that packs scope, field list, and a freshness caveat with minimal waste. The parenthetical list of fields is dense but readable and does real work since there is no output schema.

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 appropriately enumerates return fields and flags staleness, which covers what an agent needs to call and interpret it. Missing only marginal details such as result ordering or approximate list size.

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 both parameters are documented, including the ISO code format and the pointer to jumuncheck_get_guide for the city slug. The description only echoes that city is optional, adding no format or filtering nuance beyond 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 and resource (list restaurants) and bounds the scope to one country with an optional city. It also enumerates the returned fields, so an agent knows exactly what this yields. It does not explicitly name or contrast with siblings such as jumuncheck_get_guide, which only appears indirectly via 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?

The phrase 'a small hand-picked list' implies limited coverage and the closing caveat 'check before visiting' hints at verification needs, but there is no explicit when-to-use, when-not-to-use, or alternative tool guidance. An agent must infer that this is not an exhaustive search.

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, idempotent, non-destructive, closed-world behavior; the description adds that the response contains the full note text in paragraphs/markdown plus practical tips. It omits auth/rate-limit or error behavior, but for a simple read this adds useful return-shape context.

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 retrieved artifact and followed by the only prerequisite. No filler or repetition.

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 getter with full schema coverage and annotations, the description covers what is returned and where to get the required slug. It could mention the language fallback result field, though the lang parameter schema already handles that.

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 both slug and lang are already documented in schema; the description's slug-source note duplicates the schema's 'Note slug from migram_list_notes'. It adds no additional parameter semantics such as language fallback or slug format beyond 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 the exact resource ('one migram beauty note'), the content scope ('full text', 'paragraphs or markdown'), and a sibling for slug discovery. An agent can distinguish it from migram_list_notes without inspecting 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 explicitly directs the agent to migram_list_notes to obtain slugs, establishing a prerequisite and the correct discovery alternative. It stops short of stating exclusions or when a different note/trend tool should be used 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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds useful context about what the result contains (excerpts and tags, i.e., summary-level content rather than full notes), but says nothing about result volume, pagination, or truncation — relevant for a list operation.

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, zero filler: the content and returned fields come first, the routing hint to the get tool comes last. Every clause carries information an agent needs.

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 correctly compensates by listing the returned fields, and the annotations cover the safety profile. The only meaningful gap is the absence of any note about how many notes come back or whether the list can be paginated.

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%, including the language fallback rule and the pillar topic filter, so the baseline is 3. The description does add a small clarification by equating "topic (pillar)" with the returned topic field, but it does not explain filter behavior or the language parameter at all.

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

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

The description names the specific resource (short makeup and skin-care notes from migram), gives a concrete example of note content, and enumerates the returned fields (slug, title, topic, excerpt, tags). It also explicitly points at the sibling migram_get_note, so an agent can distinguish list-vs-read without inspecting 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?

It states the alternative clearly: "Read one with migram_get_note," which tells the agent to use this tool for browsing and the sibling for retrieval by slug. It stops short of saying when not to use it (e.g., versus migram_list_trends) or how the optional pillar filter selects a subset, so guidance is clear but not exhaustive.

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 a safe, idempotent, closed-world read, so the description only needs to add context. 'Featuring now' contributes a useful temporal signal (a current, changing snapshot) and the field list previews the response shape, but there is no mention of result size, ordering, or the language-fallback behavior beyond what the schema states.

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 compact sentence with the resource and returned fields front-loaded and no filler. The phrasing 'trends migram is featuring now' is slightly awkward but not wasteful.

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 zero-required-parameter, read-only list tool with annotations covering safety and no output schema, the description supplies the essential missing piece: what each result contains. Only the absence of any routing guidance against its migram siblings keeps it from a 5.

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 'lang' parameter already documents allowed values, default, and the English fallback. The description adds no additional meaning about language selection, 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 the concrete resource (makeup trends currently featured by migram) and enumerates the returned fields (title, tagline, look description, time label), which distinguishes it from migram_list_notes and migram_get_note. The list verb is only implied by the name rather than stated in the description, 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?

There is no explicit instruction on when to call this versus migram_get_note or migram_list_notes, and no exclusions or prerequisites. Usage is only inferable from the resource noun itself.

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 behavior beyond that: null semantics for missing website/about pages, contactUrl present only where one exists, and the cross-server exception for NodajiMarket with a concrete discovery pointer (/.well-known/mcp.json). It says nothing about error behavior when an app_id is unknown.

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 returned fields, and every listed item maps to something the agent will actually see in the response. The NodajiMarket caveat is a single dense clause rather than padding.

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 must carry return-value semantics and it does, enumerating the fields and their nullability. What remains unstated is the not-found/invalid app_id behavior, the only meaningful gap for a simple one-parameter read tool.

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 a single parameter and 100% schema description coverage, the schema already tells the agent that app_id comes from nodajifi_list_apps with an example. The description adds no further meaning about the parameter or its failure modes, 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 identifies the resource precisely (one app's full intro) and enumerates the payload (summary, languages, website, about/contact pages, status, dataTools), which clearly separates it from the nodajifi_list_apps sibling. It lacks an explicit retrieval verb, relying on the title's 'Get one NodajiFi app' to supply the action.

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 infers this is the detail-fetch for an id obtained from nodajifi_list_apps. There is no explicit when-to-use versus nodajifi_list_apps guidance, but the description does route the agent elsewhere for NodajiMarket products and checkout via the separate mcpServer, which is genuine routing 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, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely new context: no sign-in required and no personal data involved, plus the fact that each entry carries an availability status (available vs in development), which tells the agent what to expect in the payload.

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 no filler, and the scope statement leads. The ten-item parenthetical is long but earns its place by letting an agent judge topical relevance without a call; it could have been tightened into a list for scannability.

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 zero-parameter, read-only catalogue tool with no output schema, the description supplies both the item count and the per-item shape (one-line summary plus availability), and it names the follow-up tool for depth. Nothing needed to call it correctly or interpret the result 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?

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. It correctly spends no words on parameter explanation and instead describes what each returned item contains.

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 (list) and resource (the ten apps in the NodajiFi ecosystem), then enumerates the exact domains covered, so an agent knows precisely what is inside without opening the schema. It is clearly distinguished from its sibling nodajifi_get_app, which is named as the detail-level alternative.

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 routes the agent: use this for the catalogue overview, then call nodajifi_get_app for languages, links and which tools hold an app's public data. That is a clear selection rule, though it does not state exclusions or when not to bother with the overview at all.

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 fully covered. The description adds useful return-shape context (each card has a title, a few sentences, and a category) that substitutes for the missing output schema. It says nothing about result volume, pagination, ordering, or whether all cards are returned.

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 front-loaded sentence with no filler; the example earns its place by making an abstract category concrete. The nested quoting around 'good to know' is slightly noisy but adds branding context rather than waste.

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 two-parameter read tool with full schema coverage and annotations, the description covers what the items are and their shape, which is the main gap given no output schema. It omits how many items come back and whether results can be paged or ordered, leaving an agent unsure what a call returns.

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 lang parameter's fallback-to-English behavior is documented in the schema itself. The description only echoes 'category' as an inherent property of a card rather than explaining the filter's accepted values or semantics. Baseline 3 is appropriate because the schema carries the parameter burden.

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 identifies the resource concretely: 'good to know' cards containing short practical and cultural facts, with a concrete example (reading laundry symbols). That is enough for an agent to tell it apart from siblings like nodajifi_list_news or nodajifi_list_quotes. It never states the verb itself (listing/retrieval) and instead relies on the title and name, which keeps it just 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?

There is no when-to-use or when-not-to-use guidance, and none of the sibling tools are named as alternatives. The agent must infer from the content description alone that this is for everyday practical/cultural lookups, and nothing explains how it differs from list_news or list_quotes in a selection scenario.

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). The description adds value beyond that by specifying newest-first ordering and by managing expectations about content freshness ('not a live news feed'), which tells the agent results are curated static material rather than time-sensitive data. It stops short of describing volume ceilings or pagination behavior.

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

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

Two tight sentences: the first front-loads what the tool returns with its fields and sort order, the second delivers the key framing caveat. No redundancy or 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 usefully enumerates the returned fields and ordering, and the two optional parameters are fully covered by the schema. For a simple two-optional-parameter read-only list tool this is close to complete; only the absence of any result-size/limit interaction note keeps it from a 5.

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 both parameters (lang, limit) are fully documented in the schema, including the English fallback behavior. The description adds no parameter-level meaning beyond this, so the baseline 3 applies; 'newest first' describes ordering, not a parameter.

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 concrete resource (dated learner notes about events/announcements) and enumerates the returned fields (title, one-line summary, short text, type, date), so an agent knows exactly what comes back. It does not explicitly differentiate itself from the sibling note/quote/common-sense list tools, 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?

The clause 'learning material, not a live news feed' implies when-not-to-use (freshness/real-time purposes) which is useful negative guidance. However, no sibling alternative is named, and there is no statement of the conditions under which this tool should be chosen over nodajifi_list_quotes, nodajifi_list_common_sense, or migram_list_notes.

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, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds genuine context beyond that: the author field is as-recorded and carries a literal "Unknown" placeholder, and each record includes a category code. It says nothing about ordering, result volume, or pagination, which is the main 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?

A single compact sentence that front-loads the resource and appends the two most surprising output details. No filler, though the sentence is a noun phrase rather than a complete action statement.

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 and only one optional parameter, the description carries most of the return-shape burden and does so adequately by naming the author-with-fallback and category code fields. It would be stronger if it clarified what else a quote record holds (e.g., whether the saying text itself is returned) and whether results are paginated.

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

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

There is a single parameter with 100% schema description coverage, and that schema already spells out the eight allowed languages, the default of en, and the English fallback behavior. The description contributes nothing further about lang, 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 identifies the resource concretely as "short sayings NodajiFi shows learners" and names two of the fields returned (author, category code), which is far more specific than the bare title. It stops short of an explicit verb like "list" and does not distinguish this content type from sibling listers such as nodajifi_list_common_sense or nodajifi_list_news.

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 statement of when to call this versus the sibling list tools (apps, common sense, news) or versus nodajifi_get_app. An agent must infer usage purely from the resource noun.

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, so the safety bar is low; the description still adds real value by disclosing the per-rule payload shape (trigger, days, required action, source and section) and the caveat that unreviewed rules carry a notice. The 'not legal advice' framing is a genuine behavioral disclosure an agent needs when relaying output.

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?

Resource and scope are front-loaded in the opening clause, and the trailing disclaimers are short. The middle enumeration is dense but earns its place because no output schema exists to convey what fields come back.

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 and a single optional parameter, the description carries the return-shape burden itself and does so by listing the returned fields and the source/section provenance. Missing only guidance on how to treat the 'not yet reviewed' notice in practice and no explicit alternative-tool routing.

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 jurisdiction parameter is already documented with its three allowed values, so the schema does the heavy lifting. The description repeats the same three jurisdiction codes but adds nothing about the default behavior (omitting to get all three) or format handling, so it stays at 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?

Names the exact resource (statutory rental deadline rules ONZIP tracks) and enumerates the concrete rule families covered — condition reports, deposit returns, lease copies, deposit interest — plus the jurisdictions CA-BC, CA-AB and CA-ON. This is far more specific than the sibling names like onzip_list_services and lets an agent decide relevance 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?

The description frames the tool as reference material ('Reference information, not legal advice: follow sourceUrl') which implies a lookup use case, but it never says when to call this versus onzip_list_services or what questions it answers well. Usage is inferable from the content list rather than stated.

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 operation read-only, idempotent, non-destructive, and closed-world, so the description does not need to prove safety. It meaningfully adds that only launched countries are listed, the current release covers home records and move reports, and provider listings/prices are absent.

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 main catalog purpose is front-loaded, and most sentences add useful scope or limitations. The middle release/job-request context is somewhat tangential but helps prevent wrong expectations.

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-only catalog with annotations and no output schema, the description supplies the missing return-field and scope context. It is complete enough for an agent to call 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%, with country already documented as an optional ISO alpha-2 code and omission meaning all launched countries. The description adds the business constraint that only launched countries appear, but does not add syntax or filtering behavior beyond 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?

The description states a specific verb/resource (list the ONZIP home-services catalog), names the fields returned, and scopes it to launched countries. It does not explicitly contrast with the sibling onzip_get_deadline_rules, so it is clear but not fully disambiguated from siblings.

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

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

It gives useful boundaries—unlaunched countries are omitted, job requests are not open, and no provider listings/prices exist—but never says when to choose this tool over onzip_get_deadline_rules or other siblings. Usage is implied rather than explicitly routed.

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