akakce-mcp

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

With no annotations, the description carries the full burden, and it does disclose two useful traits: the operation is a read ('döndürür') and authentication is required. It does not mention behavior when unauthenticated (error vs. empty) or any caching/refresh semantics.

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: the return content is front-loaded, with the auth prerequisite appended as a trailing constraint. 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?

No output schema exists, so the description's field enumeration (name, email, city/district, notification count) does real work in telling the agent what comes back. Slightly incomplete in that it doesn't specify the failure mode when not logged in.

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?

Zero parameters, so there is nothing to disambiguate and the baseline is 4. The schema is empty and fully described, so the description loses nothing by omitting parameter detail.

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 (döndürür/returns) and resource (logged-in user's profile info), and enumerates the returned fields (name, email, city/district, notification count). This makes it clearly distinct from siblings like akakce_login and akakce_notifications, though it never explicitly names an 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?

The clause 'Giriş gerektirir' (requires login) gives an important precondition for calling it. However, there is no guidance on when to prefer this over siblings such as akakce_login (to establish the session) or akakce_notifications (for notification content).

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?

With no annotations, the description carries the full behavioral burden. It discloses what the tool returns (suggestions, categories, optional product codes), which is useful, but it says nothing about side effects, authentication, rate limits, empty-result behavior, or response shape. For a simple read operation this is adequate but incomplete.

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

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

Three short sentences: purpose, return contents, and usage condition. It is front-loaded and every sentence contributes without 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 one-parameter autocomplete tool with no output schema and no annotations, the description covers purpose, return values, and when to use it. It could be slightly richer about result ordering or limits, but nothing essential is missing for correct invocation.

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 already documents the single `query` parameter with an example ('rtx 5070'). The description adds purpose context but no syntax, formatting, or constraints beyond the schema, so 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 states a specific resource and behavior: it returns Akakçe search suggestions, product/category recommendations, and optional product codes for a query. This is clearly not a full search, but it does not explicitly name the sibling akakce_search as the alternative, 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?

It gives a concrete usage condition: 'If the user does not know the exact product name, first use this to find the correct phrase/code.' That is strong guidance, though it does not explicitly say when not to use it or name the competing search tool.

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?

No annotations are provided, so the description carries the full behavioral burden. It says the tool returns products and quickFilters and that filterIds narrows results, but it is silent on pagination despite a page parameter, on authentication needs, and on the shape or limits of returned product lists.

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

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

Three short sentences, front-loaded with the core action and return values, then usage guidance. Every sentence contributes either purpose, narrowing behavior, or ctCode acquisition.

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 browse tool with three parameters and no output schema, the description covers purpose, return content, and ctCode sourcing. However, it omits pagination behavior for the page parameter and does not describe the structure of the returned products or quickFilters, leaving real gaps for an agent invoking it.

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

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

The schema already describes ctCode and filterIds at 67% coverage, so the baseline is moderated. The description adds useful provenance for ctCode and restates that filterIds narrows the query, but it never mentions the page parameter, leaving that part of the schema and description both uninformative.

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

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

The description states a specific verb and resource: browsing a category code (ctCode) to return products and quickFilters. It distinguishes itself from sibling akakce_search_filters by explaining that this tool consumes ctCode, and from keyword-search siblings by explaining where a ctCode can be obtained.

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 for when to use the tool: after obtaining a ctCode from search results, product URLs, or akakce_search_filters. It also explains that filterIds narrow the browsing result. It does not explicitly state when to prefer akakce_search instead, so it falls short of a full alternatives matrix.

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?

With no annotations, the description carries the full burden; it usefully discloses that no login/auth is required and clarifies the semantic of 'deal'. However it says nothing about ordering, how many deals are returned, whether results are paginated, or freshness window – meaningful gaps for a feed tool with no output schema.

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

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

Two short sentences, front-loaded with the resource definition and followed by the auth note. No filler; every clause conveys 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?

For a no-param feed with no output schema, the description covers purpose and auth, but omits result volume, ordering, and recency semantics – details an agent would need to decide whether this tool alone answers a 'what's on sale' query.

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 and the description doesn't need to explain any; the baseline for a 0-param tool is 4. Nothing in the text misrepresents the parameter-free nature.

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 'döndürür' plus a precisely defined resource: 'son yakalanan indirimler (fiyatı yeni düşen ürünler)' – it even parenthetically defines what counts as a deal, which disambiguates from search or category_browse. It never names a sibling tool explicitly, so it stops short of full differentiation.

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 'son yakalanan indirimler' implies a browse-latest-deals use case, and the no-login note removes a prerequisite. But it gives no explicit when-to-use vs akakce_home_feed, akakce_search, or akakce_category_browse guidance and no exclusions.

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?

No annotations are provided, so the description must carry the behavioral burden. It discloses the mutation scope, batch capability, default list target, and login requirement, but it omits what happens when a product is already favorited, whether the operation is idempotent, and what the response contains.

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 short and front-loads the purpose before giving input and authentication notes. The sentence telling the caller to provide product codes is somewhat redundant with the schema, but overall it is appropriately sized.

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 one-parameter mutation, the description covers purpose, authentication, and target list. It leaves notable gaps around duplicate handling and the result of the operation, and there is no output schema or annotation coverage to fill those gaps.

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

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

The schema fully documents the single 'codes' parameter, including its array type and minimum item count. The description reinforces that product codes may be singular or plural, but adds no format or validation details beyond the schema, so the 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 states a specific verb and resource: it adds one or more products to favorites, with the default list explicitly named. This clearly separates it from removal or listing operations by behavior, though it does not explicitly name the sibling tools.

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

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

The description gives a key prerequisite, 'Giriş gerektirir' (requires login), and clarifies that the target is the default favorites list. However, it does not state when to prefer this over akakce_favorites or akakce_favorite_remove, so usage is implied rather than fully 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?

No annotations are provided, so the description carries the full burden. It does disclose the critical auth prerequisite ('Giriş gerektirir'), which is genuinely useful, but says nothing about reversibility, idempotency, or what happens if the product is not in the list.

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

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

Three short sentences: action first, then parameter sourcing, then the auth prerequisite. Zero filler and front-loaded.

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

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

For a simple two-required-param mutation with no output schema, the description covers the action, parameter sourcing, and the login requirement. Only failure modes and effect of a missing product are absent.

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

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

Schema coverage is 100%, so baseline is 3; the description earns above baseline by explaining how to obtain the listId via akakce_favorites, which the schema does not say. Both required params are acknowledged, though their types and semantics remain entirely in 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: 'Bir ürünü favori listesinden çıkarır' (removes a product from the favorites list). The removal framing distinguishes it from the sibling akakce_favorite_add, though it does not name that sibling directly.

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

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

Gives concrete operating guidance by naming where listId comes from ('listId'yi akakce_favorites'ten al'), effectively routing the agent to the sibling that produces the prerequisite value. It does not state explicit when-not-to-use conditions, which keeps it below 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?

With no annotations provided, the description carries the full burden, and it does disclose the authentication requirement plus the exact contents returned in each mode (id/name/product count vs name/price/url). It stops short of mentioning pagination, rate limits, or what happens with an invalid listId, leaving a few behavioral gaps.

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 compact sentences with zero waste; the primary purpose is front-loaded, the parameter branching follows, and the auth caveat closes it. Nothing is redundant with the schema or 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?

There is no output schema, yet the description enumerates the returned fields for both modes, so an agent can act on the result without guessing. Combined with the auth note, this is nearly complete for a one-parameter read tool; only edge-case error behavior is absent.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine semantic value by explaining the omitted-vs-supplied branching behavior of listId, which the schema alone does not convey. It also confirms the id comes from this tool's own output, reinforcing the schema's note.

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 ('Favori listelerini döndürür') and spells out the two distinct output modes keyed on listId, so the agent knows exactly what it gets back. It does not explicitly contrast itself with akakce_favorite_add/remove, but the read-oriented return description implicitly separates it from those mutations.

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

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

Gives a clear conditional rule: omit listId to enumerate all lists, supply listId to get that list's products. It also discloses the login prerequisite ('Giriş gerektirir'), which is essential context for deciding whether the call will succeed. No explicit alternative tool is named, but the usage context 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?

No annotations exist, so the description carries the full burden. It does disclose that no login is required and that the payload consists of page components plus redirect URLs, but it says nothing about side effects, caching/staleness, rate limits, or result ordering. For an effectively read-only zero-parameter feed this is adequate but thin.

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 the return payload and the parenthetical examples are useful rather than filler. The auth note is a compact, relevant addendum; no padding 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?

The tool is structurally simple (no params, no output schema, no annotations), and the description covers what comes back and the auth requirement. The main gap is that return shape (component structure, URL field names) is left unstated and there is no output schema to compensate.

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

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

The tool takes no parameters and the schema is an empty object, so there is nothing for the description to disambiguate. Baseline of 4 applies.

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

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

The description names a specific verb ('döndürür' / returns) and a concrete resource (the Akakçe homepage components), and it enumerates what those components are (discover/slider cards, current products, campaigns, collections). It does not differentiate itself from siblings such as akakce_deals or akakce_category_browse, which keeps it from 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: the reader can infer this is the homepage/landing entry point that yields navigation URLs and promotional cards. There is no explicit when-to-use signal, no statement of when a different sibling would be preferable, and no exclusions. The 'no login required' line is a prerequisite note rather than routing 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?

With no annotations, the description does useful work by disclosing that it only runs with Fire-Pass guarded Kimi K2.6 Turbo and is disabled when FIREWORKS_API_KEY is not defined. However, it omits other important behavioral details such as output shape, latency/cost implications, and error behavior for an external LLM 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?

The description is front-loaded with purpose, then adds only material constraints: the specific model, the API-key requirement, and the expected input source. Every sentence contributes useful information 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?

For a two-parameter LLM wrapper with no output schema, the description covers purpose, input source, and runtime dependency. It does not explain the return format, which matters because the agent cannot otherwise know whether it will receive text, JSON, or structured results.

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 parameters are already documented. The description reinforces the data source by saying to pass JSON from other akakce_* tools, but adds little beyond the schema's own descriptions of data and instruction.

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

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

The description states a specific verb and resource: it interprets Akakçe search/price results with an LLM, and enumerates concrete operations (summarize, normalize, compare, filter by instruction). This clearly distinguishes it from the retrieval-oriented akakce_* 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 clear usage context by telling the agent to pass JSON obtained from other akakce_* tools (products/sellers). It does not explicitly state when not to use it or name alternatives, but the input-source guidance is concrete.

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?

With no annotations, the description carries the full burden and does well: it names the persisted artifact (session cookie file path), the credential source fallback (AKAKCE_EMAIL/AKAKCE_PASSWORD), and session validity. It doesn't cover failure behavior (bad credentials) or whether an existing session is overwritten, which keeps it from 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?

Four short sentences, front-loaded with the action and its side effect, then the dependency unlock, then credential sourcing, then session lifetime. Nothing is redundant enough to cut.

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?

No output schema exists, and the description explains persistence and lifetime but not what the call returns on success (e.g., account identity or a confirmation), which an agent might want. Otherwise complete for a two-optional-param auth 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 100% and both parameter descriptions already state the env-var fallback, so the description's credential-fallback sentence largely repeats structured data. Baseline 3 applies since 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?

States a specific verb+resource ('Akakçe hesabına giriş yapar') and discloses the concrete side effect (AAATLGST cookie saved to ~/.config/akakce-mcp/session.json). This clearly separates it from the sibling akakce_logout and from the read-only browsing tools.

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?

Says login unlocks favorites, price alerts and notification tools, which gives the agent the prerequisite condition for those siblings, and notes the ~1-year session lifetime so repeat logins are unnecessary. It stops short of an explicit 'call this if an auth-required tool fails' routing statement.

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?

With no annotations provided, the description carries the full burden. It helpfully identifies the exact target of deletion (session.json), but does not state whether the deletion is irreversible, whether it requires authentication, or what state the agent is left in after the session is removed. For a simple local file deletion this is adequate but incomplete.

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

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

A single short sentence that front-loads the action and the target. Nothing is wasted, and no important information is buried.

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, no-output-schema logout tool, the description is sufficient to understand the call. It could be improved by mentioning that no arguments are required and what effect the deletion has on subsequent calls, but the core is complete.

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

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

The tool accepts zero parameters, so there are no parameter semantics to explain; the baseline of 4 applies. No description text is needed to compensate for missing parameter documentation.

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 ('siler' = deletes) and resource ('Kaydedilmiş Akakçe oturumu' / session.json), making the action unambiguous. It is the only logout tool among siblings, but it does not explicitly contrast itself with akakce_login or other session-affecting tools.

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 name and description—clear the saved session when you want to log out or reset authentication. However, there is no explicit statement of when to use this versus other tools, no prerequisites, and no note about what happens afterward (e.g., needing to re-login).

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?

No annotations exist, so the description carries the full burden. It discloses the auth requirement and the shape of the returned data, which are real additions, but it is silent on whether fetching marks notifications as read, whether results are paginated or capped, and what an empty result looks like.

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

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

Two short clauses, no filler: the return content comes first and the auth prerequisite second. Every element earns its place.

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

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

For a zero-parameter read with no output schema, the description does the essential work by naming the returned fields and the login requirement. Minor gaps remain around read-state side effects and result limits, but an agent can call this correctly from what is given.

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. Listing the returned fields is a small bonus but does not change the fact that parameter semantics are a non-issue here.

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 ('Fiyat düşüşü bildirimlerini döndürür' – returns price-drop notifications) and enumerates the payload fields, so the agent knows exactly what comes back. It does not, however, distinguish itself from the closely named siblings akakce_price_alerts and akakce_price_alert_set, leaving the notifications-vs-alerts boundary to 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 only usage signal is the precondition 'Giriş gerektirir' (requires login), which is genuinely useful. There is no statement of when to prefer this over akakce_price_alerts, nor any exclusion or alternative named, so usage is only implied.

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?

With no annotations, the description carries the behavioral burden. It discloses the authentication requirement and names the fields returned, which are useful beyond structured data. It does not state pagination, ordering, or failure behavior, but for a zero-parameter read listing it is fairly transparent.

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 clauses, front-loaded with the action and return fields, then the login requirement. Every sentence adds useful information with no 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?

No output schema exists, so the description usefully enumerates the returned fields and the auth prerequisite. For a simple zero-parameter listing tool this is nearly complete, though pagination or empty-state behavior is not mentioned.

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

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

The tool has zero parameters, so there are no parameter semantics to document; this is the baseline score for a no-argument tool. The description appropriately does not invent parameter details.

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: lists configured price alerts. It also names the returned fields (product, target price, current price), so the purpose is clear. It does not explicitly distinguish itself from siblings such as akakce_price_alert_set, but the 'list' verb separates it adequately.

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

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

The description implies usage for viewing existing alerts, and the login requirement gives a prerequisite. It does not say when to use this instead of akakce_price_alert_set, akakce_notifications, or other alert-related siblings, so guidance is only implied.

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?

With no annotations, the description carries the full burden. It usefully discloses that the tool creates or updates an alert, that a notification fires when the target price is reached, and that login is required, but it omits behavior such as what happens to an existing alert, error handling when unauthenticated, and whether the call returns a confirmation.

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 tight sentences with the core action and trigger front-loaded. Every clause adds useful information with no wasted wording.

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 tool with no output schema and no annotations, the description covers the main purpose, required inputs, trigger behavior, and login requirement. It still leaves gaps around return behavior and how existing alerts are handled, so it is adequate but not complete.

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

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

Schema description coverage is 100%, so both 'code' and 'targetPrice' are already documented. The description restates their meaning and adds the trigger semantics, but does not provide syntax or format details beyond the schema, making the baseline 3 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 gives a specific verb/resource: 'fiyat alarmı kurar/günceller' for a product, with the trigger condition 'fiyat hedef değere düşünce bildirim gelir'. It is clear what the tool does, though it does not explicitly distinguish itself from sibling tools like akakce_price_alerts or akakce_notifications.

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 required inputs and that login is required, which implies when the tool is usable. However, it does not explicitly say when to choose this over akakce_price_alerts or how it relates to notification listing.

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?

With no annotations, the description carries the full burden and does well: it discloses that the tool returns only a PNG chart with zero numeric data points and that the result is a directly viewable image URL. It omits auth/rate-limit or failure behavior, keeping it short of 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?

Three short sentences, front-loaded with the core behavior and the critical image-only constraint, 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?

There is no output schema, and the description compensates by explaining the return value (a direct chart image URL, no numeric series). For a simple two-parameter read tool that is nearly complete, with only auth/error context missing.

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

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

Schema description coverage is 100%, so both parameters are already documented; the description only adds that the product `code` alone is sufficient (making `url` effectively redundant). That is a useful hint but not substantial beyond-schema meaning.

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

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

States a specific verb and resource: returns a product's price-history chart. It implicitly distinguishes itself from price-data siblings (e.g. akakce_product_prices) by stressing that the history is only an image with no numeric data points, though no sibling is named explicitly.

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

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

'Sadece ürün code'u yeterli' gives minimal usage context, and the image-only note implies when this is preferable to numeric price endpoints. But there is no explicit when-to-use/when-not statement and no named alternative for retrieving numeric history.

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?

No annotations exist, so the description carries the full load, and it does disclose the return payload in detail plus the non-obvious behavior that the URL is resolved automatically from the code. It does not mention authentication, rate limits, or what happens when a code is invalid, which are the remaining behavioral gaps.

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?

Front-loaded with the outcome (full detail plus all sellers) before the parameter tactics, and every clause carries information — the field enumeration, the auto-resolution, and the url shortcut each earn their place.

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

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

With no output schema and no annotations, the description compensates well by enumerating the returned fields and the seller-list contents. Missing only edge-case behavior (errors, auth, whether the seller list is paginated or capped) for a fairly simple two-optional-param 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 already 100%, so the baseline would be 3, but the description adds real meaning: `url` is an optional shortcut that costs one fewer request, and its value originates from akakce_search results. That is a usage relationship the schema text does not fully convey.

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 (döndürür) and resource (bir ürünün tam detayı) and enumerates exactly what comes back: name, brand, specs, rating, price range, and the full seller list. This lets an agent distinguish it from sibling tools like akakce_product_prices and akakce_quickview without opening their 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?

Explicitly says `code` alone is sufficient and that passing `url` (the productUrl from akakce_search) skips one request, giving a concrete provenance and a performance-based choice between the two params. It stops short of naming when to prefer this over akakce_quickview or akakce_product_prices, so it is strong 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the returned fields and bulk behavior, but does not mention authentication needs, rate limits, error behavior, or whether it is strictly read-only.

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 short and front-loaded: it states the purpose first, then the returned fields, then sourcing and bulk guidance. Every sentence adds useful information without 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 single-parameter tool with no output schema, the description is largely complete: it explains the purpose, return fields, and where to obtain valid codes. The main remaining gaps are error behavior and operational constraints, which are minor given the tool's simplicity.

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 already 100%, so the baseline would be 3. The description adds meaning beyond the schema by explaining that codes should come from search or autocomplete results and that multiple codes can be supplied in one bulk call.

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 action and resource: it returns the cheapest sellers for one or more product codes from Akakçe, along with the returned fields. It is clear but does not explicitly distinguish this tool from the similarly named sibling akakce_quickview.

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 sourcing guidance, telling the agent to get product codes from akakce_search or akakce_autocomplete, and encourages batching multiple codes. However, it does not say when to use this tool instead of akakce_quickview, akakce_product_detail, or akakce_price_history.

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?

No annotations exist, so the description carries the full burden. It does add valuable auth context ('Giriş gerektirmez') — relevant given the akakce_login sibling — but says nothing about return shape (what fields describe a 'cheapest seller'), behavior for an invalid/unknown code, or whether results are cached/rate-limited.

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

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

Two short sentences with zero padding: the operation and scope come first, the sibling comparison and auth note follow. Every clause earns its place.

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

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

With one required param and no output schema, the description needs to carry return-value expectations; it only says 'cheapest seller(s)', leaving the response structure (price, seller name, currency, ranking) unspecified. The auth note helps, but for a network-backed lookup tool the behavioral picture is still thin.

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 parameter is already documented as 'Ürün kodu'. The description only echoes that ('tek bir ürün kodu için') and adds no format, range, or sourcing 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 and resource ('en ucuz satıcı(ları) hızlıca döndürür') scoped to a single product code, and explicitly names the sibling it is a reduced form of (akakce_product_prices). An agent can distinguish it from the other 19 akakce tools 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?

Names the alternative (akakce_product_prices) and characterizes this one as its 'tekli/hafif sürümü', which signals the single-product, lightweight use case. It stops short of an explicit rule for when to prefer the fuller sibling (e.g. batch codes or extra fields), so the choice is implied rather than fully prescribed.

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?

No annotations exist, so the description carries the full burden. It does usefully disclose the exact return fields (name, brand, lowest price, seller count, rating, product code, URL) and that the product code feeds price/detail calls. It says nothing about pagination limits, auth requirements, or rate limiting, leaving meaningful behavioral gaps.

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 dense sentences with no filler: purpose first, return fields second, pagination/filtering last. Well front-loaded, though the return-field enumeration is long enough that it slightly crowds the actionable guidance.

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 enumerating the returned fields, and it covers the key filtering/pagination mechanics for a 5-parameter search tool. Minor gaps remain around result limits and cross-tool routing, but nothing an agent needs to call it is missing.

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

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

Schema coverage is 100%, so the schema already defines all five parameters and the baseline would be 3. The description adds value beyond the schema by explaining that filterIds should be sourced from akakce_search_filters and that ctCode+filterIds combine for filtering, giving an agent the provenance it needs.

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 ('Akakçe'de ürün arar') plus the return shape (price list), making the core action unambiguous. It does not explicitly differentiate itself from search-adjacent siblings like akakce_deals or akakce_autocomplete, 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?

Gives clear operating context: pagination via 'page', filtering via 'ctCode + filterIds', and explicitly routes the agent to akakce_search_filters to obtain filter ids. It never states when NOT to use this versus sibling search/browse tools, so no exclusions are provided.

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?

No annotations are provided, so the description carries the full disclosure burden. It does describe the return payload (filter groups and their ids) and the downstream chaining behavior, but says nothing about authentication, whether results are cached or live, or any 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?

Two tight sentences: the first declares what is returned, the second declares how to use the result. Nothing is wasted and the key information is front-loaded.

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

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

For a two-parameter read tool with no output schema, the description adequately conveys the output's shape and purpose. However, the undocumented sort parameter and the absence of any hint about result size or filter availability mean the definition is only minimally sufficient.

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 only 50%. The phrase parameter's schema text ('Arama ifadesi') merely restates the name, and the description repeats 'arama ifadesi' without adding format or example guidance. The sort parameter (default 1) is unexplained in both the schema and the description, leaving its accepted values opaque.

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

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

The description names a specific verb and resource: it returns the applicable filter groups (brand, feature, RAM, etc.) and each filter's id for a given search phrase. That is concrete and distinguishable from siblings such as akakce_product_detail or akakce_deals, though it never contrasts itself directly with akakce_autocomplete or akakce_category_browse.

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 intended workflow explicitly: call this to obtain filter ids, then pass those ids to akakce_search as filterIds to narrow results, which effectively names the alternative and the condition for chaining. It stops short of stating when not to use it, such as when no filtering is needed.

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