Yapay Zeka Yazılımları

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 material context beyond that: a ~12k character truncation cap on returned content and an explicit six-domain allowlist that defines the closed world in concrete terms. Return-format disclosure is a further plus, though nothing is said about error behavior or redirects.

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 first covers action, source and return payload with the truncation limit; the second front-loads the hard constraint. Every clause carries information the 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?

For a one-parameter read tool with no output schema, the description supplies what structured fields cannot: the shape of the returned content and its size ceiling. Combined with annotations covering the safety profile, an agent has everything needed to call 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 single url parameter is already documented as 'Full https URL on one of the six sites'. The description earns extra credit by actually enumerating the six permitted domains, which the schema only alludes to, making the constraint actionable without a trial 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 gives a specific verb ('Fetch') and resource ('a page'), names the site family, and states exactly what is returned (title, description, markdown body). It stops short of explicitly contrasting with the sibling search_content, so the agent must infer the fetch-vs-search split, but the core purpose is 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?

The when-not case is encoded as a domain allowlist ('Only these domains are allowed' plus the six listed hosts), which tells the agent when a call will fail. However, there is no guidance on when to prefer this over search_content or site_overview, so usage is only implied 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: prices are in TRY, VAT excluded, static and identical to the public website, and the model must not fabricate alternatives.

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 return content and ending on the anti-fabrication constraint. The category list is dense but each item earns its place by defining scope; 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 zero-required-parameter, read-only lookup with annotations covering safety, the description supplies enough: what comes back, currency, tax treatment, and authority. With no output schema, it could have sketched the response structure slightly more concretely, but nothing critical 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% and the single enum parameter is self-documented with a default, so the baseline is 3. The description goes further by mapping the enumerated content areas to the enum's service categories (websites, e-commerce, custom software, training), clarifying what each selection yields.

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 Yazılım Koçu's published prices — and enumerates the covered categories (website, e-commerce, custom software, AI training). It does not name a sibling such as quote_website, so the boundary with quoting tools is left implicit.

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: fetch published list prices, and 'never invent other prices' establishes this as the authoritative source. There is no explicit when-to-use/when-not guidance and no routing to quote_website for a bespoke estimate, which an agent would likely need.

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 new behavioral context: result ordering favors the current satellite site then hub pages, and it signals that results are references to be opened with get_page rather than full content.

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 what is searched, then result ordering, then the next step, then a usage tip. Nothing is redundant with the schema and no sentence is filler.

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

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

With no output schema, the description carries the burden of explaining what comes back, and it does so indirectly by describing ordering and that results must be read via get_page. It stops short of describing result shape or how the limit interacts with result count, but the essentials for correct invocation are present.

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 all three parameters are already documented, including the site/all enum. The description still adds value by showing the intended query language and giving concrete Turkish query examples, and by explaining what "site" scope actually yields (this site plus top hub pages).

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

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

The description opens with a specific verb and an enumerated resource set: "Search published articles, buyer guides, solution pages, tools and design demos." This clearly distinguishes it from sibling tools that list one content type (list_design_demos, list_services) or fetch a single page (get_page).

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 explicit follow-up routing ("Use get_page to read a result") and explains the ordering behavior on satellite sites, which tells the agent what to expect from results. It does not, however, say when to prefer this over the list_* or get_frameworks siblings when browsing rather than searching.

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 by structured data. The description adds that the payload is descriptive context about the publisher and network, but says nothing about response size, shape, or whether it is static cached text. With annotations doing the heavy lifting, this is adequate rather than rich.

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 content scope stated before the usage directive. 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?

For a zero-parameter, read-only orientation tool with no output schema, the description covers what an agent needs to decide to call it. The only gap is that it does not characterize the returned content's form (e.g., a prose summary vs. structured list of network sites).

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. The description correctly implies a parameterless, always-available call by framing it as a general orientation step.

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 a concrete set of resources: describing the website, its publisher (Yazılım Koçu), its topics, and the other sites in the network. That is far more informative than the title 'Site ve ekip tanıtımı' alone, though it never explicitly contrasts itself with siblings like get_page or list_services.

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?

'Call this first when you need context about the site' gives a clear triggering condition and an ordering preference relative to other tools. It stops short of naming when not to use it or which sibling supersedes it for narrower lookups.

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 description only needs to add what they cannot. It does add real value: the output is an exact form link, and there is an explicit data-handling constraint (no name/e-mail/phone in chat, KVKK consent happens on the form). It does not say what happens if the wrong 'need' value is chosen or whether the link is stable across calls.

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, trigger condition first, constraint second, with no redundant restatement of the tool name or schema. Every clause carries actionable 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 one-parameter, no-output-schema tool with full annotation coverage, the description supplies what an agent needs: when to fire, what is returned (a form link), and the privacy constraint. The only gap is disambiguation from siblings that also serve offer/training intents.

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

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

Schema description coverage is 100% and the single 'need' parameter carries a fully enumerated 15-value list documented in the schema, so the baseline is 3. The description only echoes this with "for that need" and adds no guidance on how to pick among overlapping enum values like 'egitim' vs 'kurumsal-egitim' or 'diger'.

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

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

The description names a concrete action ("return the exact Yazılım Koçu form link") plus the triggering needs (offer, meeting, project, training), which is far more specific than the title alone. It does not explicitly contrast itself with overlapping siblings such as quote_website or get_training_options, so an agent must infer the boundary between requesting a link and getting pricing/training details.

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?

Trigger conditions are stated clearly ("When the user wants an offer, a meeting or to start a project or training"), and a negative rule is included ("Do NOT collect personal data ... in the chat"). It stops short of naming which sibling tool to use for adjacent intents, so the when-not guidance is partial.

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