hangel

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 covered. The description adds the useful distinction that this returns the *full* record versus a search result stub, but says nothing about error behavior for malformed ids or whether private/unpublished records are excluded.

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 the core action first and the id examples as trailing illustration. No filler, no restating 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 one-parameter, read-only lookup with full annotation coverage and no output schema, the description gives enough to invoke it correctly. The only gap is that 'full public record' is not characterized in any way (fields, size, shape), so the agent cannot anticipate what comes back.

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 only says the id comes from search, so the description's prefix examples (ngo:, event:, volunteer:, fund:, store:, product:, library:, page:) are genuinely additive — they tell the agent the expected id grammar and the set of entity types. Slightly above baseline because of that concrete format guidance.

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

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

States a specific verb (fetch) and resource (the full public record) and anchors it to an id produced by the sibling tool search, so it is immediately distinguishable from list_* and search_* tools. The enumerated id prefixes make the scope concrete.

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 establishes the prerequisite that the id must come from search, which routes the agent away from guessing ids. It stops short of stating when-not to use it (e.g. use list_* for enumeration) or what happens on an invalid/unknown id.

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 useful behavioral scope (only upcoming/ongoing, only public events, no past events), but says nothing about result ordering, pagination behavior, or what happens when filters are combined.

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 states resource, temporal scope, source scope, and filters with no filler.

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

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

With four optional params, no output schema, and rich annotations, the description covers everything needed to call the tool correctly. The only gaps are result ordering and pagination, which are minor for a zero-required-param listing 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?

Schema coverage is 50%: `limit` and `online` are documented in-schema, while `city` and `query` are bare. The description compensates partially by mapping 'keyword' to `query` and confirming the `city` and online-only filters, but adds no matching semantics (partial match, case sensitivity, city naming).

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

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

Specific verb+resource with scope: 'List upcoming and ongoing public events' and even names the publisher types (NGOs, student clubs, institutions). It is clearly distinguishable from the sibling lists (list_volunteering, list_open_funds, list_stores) by resource alone, though it never explicitly names 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?

The phrase 'optionally filtered by keyword, city or online-only' implies the intended usage contexts, but there is no statement of when to prefer this over `search` or `fetch`, and no exclusions or prerequisites.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile needs no restating. The description adds genuinely new context beyond them: the result set is restricted to calls whose application window is open, and it names the fields each record carries, which matters because no output schema exists. Pagination/default behavior is left to the 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?

A single sentence with the scope constraint front-loaded and the returned fields in a compact parenthetical; no filler or restatement 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, no-required-argument read tool with full annotation coverage, this is close to sufficient, and describing returned fields compensates for the absent output schema. Only result ordering/total-count behavior is unaddressed, which is a minor gap.

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

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

Schema description coverage is 100%, with both limit and query documented in the schema itself, so the baseline of 3 applies. The description adds nothing about query matching semantics or how limit interacts with result ordering beyond what the schema already says.

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 grant and funding calls') plus a real scope constraint ('currently open for applications'), and enumerates the payload fields (deadline, provider, support amount, focus areas). It does not explicitly distinguish itself from the list_* siblings, though the resource noun makes the distinction obvious.

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 'currently open for applications' clause implicitly tells the agent when this tool applies versus a general search, but there is no explicit when-to-use, no exclusion of closed/archived calls, and no named alternative (e.g. using search for keyword discovery beyond the open set).

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 carry the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is additive — and it delivers by disclosing the default sort order and defining the donation-rate field, which the agent wouldn't otherwise know. It stops short of noting result-volume/pagination behavior tied to `limit`.

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 zero filler: resource, scope, sort order, and field meaning packed into one clause each. Nothing is repeated from the schema 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?

With only two parameters, full schema coverage, annotations present, and no output schema, the definition covers what an agent needs to call it: what it lists, in what order, and what the donation rate means. A brief note on how `query` interacts with ranking (does filtering preserve the donation-rate sort?) would close the remaining gap.

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

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

Schema coverage is 100%: both `limit` (default 50, max 200) and `query` (store name or category) are documented in the schema. The description adds no further parameter detail, so the baseline 3 applies.

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

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

States a specific verb and resource ('List partner stores on hangel Market'), plus the ordering ('highest first') and the meaning of the key returned field ('donation rate — % of each purchase donated'). Sibling tools cover clearly different resources (events, funds, volunteering, NGOs, products), so an agent can route to this one without opening the schema.

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

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

Usage is implied by the resource name — browse partner stores with their donation rates — but there is no explicit when-to-use/when-not or reference to an alternative (e.g., using `search` for keyword lookups instead of browsing). The 'highest first' note hints at a ranking/browse use case but is not framed as guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world behavior. The description adds filter context but does not disclose pagination behavior, result ordering, or other behavioral details beyond the 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?

A single front-loaded sentence with no wasted words. The core purpose appears before the optional filter list.

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 list tool with five optional parameters and clear annotations, the description is nearly sufficient. Minor gaps remain around result pagination and filter value formats, but the schema covers the limit and key query behavior.

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 60%, with descriptions for limit, query, and online, but city and urgentOnly lack schema descriptions. The description names most filters but adds little syntax or format detail, and does not mention the limit 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?

The description states a clear verb and resource: list open volunteering opportunities. It is distinguishable from sibling list tools by resource, but does not explicitly contrast with alternatives such as search or list_events.

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

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

It implies usage through the optional filters (keyword, city, online/remote, urgent only), but does not state when to use this tool versus siblings or when not to use it.

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 fully covered elsewhere. The description adds useful scope context by naming the specific facts and sections returned, but says nothing about response shape or that results are static/cacheable, which would be the genuinely additive disclosure here.

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?

It is a single compact sentence with no filler, and the core 'what hangel is' item is front-loaded. However, eight items are crammed into one comma-delimited run-on, which makes the scope harder to scan than a short structured list 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 zero parameters, no output schema, and annotations covering safety, the description carries most of the burden of telling the agent what it will receive — and the enumerated topics do exactly that. A note on response format or standing/staleness of the content is the only meaningful gap.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to compensate for. The description's topic list effectively signals that all content is returned unconditionally rather than being selectively filtered.

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 concrete topics the tool returns (what hangel is, donation-through-shopping mechanics, trust facts, languages, pages, library sections), which makes the resource identifiable as a static platform-overview tool. It stops short of explicitly contrasting itself with siblings like search_library or list_stores, so an agent must infer that this is the non-searchable 'about' entry point.

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 sentence states when to call this versus fetch, search, or the list_* siblings, and no exclusions are given. Usage is only implied by the content list — an agent can guess it belongs at onboarding or when a user asks 'what is hangel', but that routing decision is left 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 establish read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds real value by disclosing the return shape (ids, not full records) and the scope restriction to 'public' content only — two things an agent could not learn from the annotations.

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

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

Two sentences, zero filler. The scope enumeration is front-loaded and the chaining hint follows immediately. Nothing could be removed without losing information.

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

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

With no output schema, the description correctly compensates by stating that ids are returned and pointing to fetch for the actual records. What remains thin is the absence of any tie-break against the six sibling search/list tools, which an agent routing a query genuinely needs.

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?

One required parameter with 100% schema description coverage, so the baseline of 3 applies. The description adds only the word 'keyword', and the TR/EN acceptance detail is already in the schema, so it contributes nothing beyond structured fields.

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 (search) and an explicitly enumerated resource scope — NGOs, events, volunteering, funding calls, stores, products, library, pages — so the agent knows exactly what corpus is covered. It implicitly distinguishes itself from entity-specific siblings via 'everything public', but never names them, 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?

The phrase 'Returns ids for the fetch tool' gives a useful workflow cue — this is a discovery step that must be chained into fetch. However, there is no guidance on when to prefer this broad search over search_ngos, search_products, or search_library, and no mention of result limits or query behavior.

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=true, idempotent=true, openWorld=false, destructive=false, so the safety profile is fully covered structurally. The description adds the useful fact that this is a bounded internal corpus (a specific library) rather than an open web search, but says nothing about result ordering, pagination, or the sections mechanism.

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 corpus list earns its place by defining scope. It is dense but readable, and would only be stronger with one clause on when to prefer a sibling 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 simple three-parameter read tool with no output schema, the essentials are present, but the description omits how `section` should be obtained (from platform_info or a prior response) and gives no hint about result shape or result-count behavior. Adequate but with clear gaps for an agent planning a multi-step 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 67%: `limit` and `section` are documented in the schema, while `query` has no schema description. The description does not compensate for that gap (no note that query is free-text/keyword based) nor clarify how `section` relates to the returned sections list. Baseline 3 fits given the schema does most of 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 (search) plus the resource and enumerates the corpus it covers (legislation, templates, research, articles, books, films, glossary), which implicitly separates it from siblings like search_ngos and search_products. It never explicitly names those alternatives, so differentiation is by content domain rather than by routing instruction.

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 content enumeration implies what this tool is for, but there is no explicit when-to-use statement, no guidance on choosing it over the generic `search` or `search_ngos`, and no mention of when to pass `section` versus starting fresh. Usage is inferable but not guided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that matching spans name, short name, cause area and about text, but says nothing about result ordering, total-count behavior, or the effect of omitting all filters.

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 resource and every filter dimension are packed in without redundancy.

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

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

For a read-only, annotation-covered search with a fully documented 4-parameter schema and no output schema, the description gives enough to call it correctly. It could still note that all parameters are optional and that omitting them returns an unfiltered list, which is the only real gap.

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

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

Schema description coverage is 100% (Turkish descriptions for city, query, minTransparency, limit, including the 0-100 range and the 50-result cap). The description's mention of keyword/city/cause area/transparency score merely mirrors those fields, adding no format or syntax detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (Find) and resource (NGOs / associations / foundations) plus the four filter dimensions, which separates it from generic siblings like search and search_products. It does not explicitly name a sibling it is not, 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?

The sentence describes what the tool searches but never says when to choose it over search, search_library or search_products, nor whether all filters are optional and it can be used as a plain listing. No exclusions or prerequisites are given; usage is only inferable from the resource name.

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 not open-world. The description adds domain context about partner stores and donation rates, but does not provide operational behavior such as result shape, pagination, auth, or rate limits.

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 two sentences and front-loads the core action. The second sentence is contextual rather than operational, but it earns its place by explaining the donationRate concept referenced in the 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?

For a three-parameter search tool with full schema coverage and safety annotations, the description is mostly complete. The main gaps are the lack of explicit alternative-tool routing and return-value expectations, which are less critical but still absent without an output schema.

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

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

Schema description coverage is 100%, so the schema already documents query, limit, and minDonationRate. The description explains what a donation rate means, but it does not add usage semantics for the minDonationRate filter or clarify query/limit 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 uses a specific verb and resource: 'Search hangel Market products.' It also scopes the catalog as 'millions of items from partner stores,' which distinguishes this tool from generic siblings like search, search_ngos, and search_library.

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 intended use is implied by 'Search hangel Market products,' but the description never explicitly says when to use this instead of the generic search tool or other sibling search tools. No exclusions or alternative-routing guidance are provided.

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