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

With no annotations at all, the description carries the full burden, and it does disclose a meaningful side effect (writes Parquet) plus a return shape (path, dimensions, skipped items). However it omits where files land, whether existing panels are overwritten, and what 'atlananlar' (skipped) means operationally — all important for a write tool with zero annotation coverage.

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

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

A single compact sentence that front-loads the action and outcome with no filler. It is efficient, though at the cost of the parameter and behavioral detail noted above.

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?

Three parameters with zero schema descriptions, no annotations, and no output schema; the description partially covers the return value but leaves the start/end date semantics and write behavior unexplained. For a tool that creates persistent artifacts, this is under-specified.

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 0%, so the description must compensate and largely fails: it only alludes to 'sector' via 'Sektörün'. The start and end parameters — including their date format, defaults, and whether end is exclusive or optional — are never mentioned in the description or 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 (üretir = builds), a specific resource (aylık panel from the sector's macro features), and the materialization target (Parquet). This is clearly distinguishable from siblings like fetch_series or list_sectors, though it never names an alternative 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?

There is no statement of when to use this tool versus fetch_series or discover_series, no prerequisites, and no exclusions. The agent must infer from the word 'panel' and 'Parquet'e yazar' that this is a batch materialization step rather than a data-read step.

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, and it does disclose one meaningful trait: the tool may perform a live network call to /serieList versus returning static catalog data, which is real behavioral information. It omits any note on latency, failure modes, or that both parameters default (so a bare call is valid), which matters for a tool with a remote branch.

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 with the core action front-loaded and the conditional branch immediately after; no filler. Slightly compressed to the point that the omitted source parameter would have fit without harming brevity.

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?

An output schema exists, so return values need not be explained, and both parameters are optional with defaults. Still, the undocumented source parameter and the absence of any guidance on choosing this over fetch_series leave an agent with a gap before it can call confidently.

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

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

Schema coverage is 0%, so the description must compensate. It does explain the datagroup parameter's meaning and gives a concrete example format (bie_dkdovizgn), which is valuable beyond the bare string type. However, the second parameter, source (default 'evds3'), is never mentioned anywhere, leaving half the parameter surface undocumented.

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 action (series discovery) with two clearly distinguished output modes: live /serieList when a data group code is supplied, catalog seed series otherwise. It never positions itself against siblings such as fetch_series or list_sources, so an agent must still infer the boundary.

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 genuine conditional: pass a datagroup code to hit the live endpoint, omit it to get seed series from the catalog. That implies when to call it, but there are no exclusions and no comparison to the retrieval-oriented siblings (fetch_series, list_sources), so the agent is left to guess whether to discover or fetch.

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 burden. It does disclose two important traits a schema cannot: the tool writes to a local silver layer (a mutation/persistence side effect) and returns a summary plus the last max_rows rows. It omits overwrite/refresh behavior, auth, rate limits, and error handling for bad codes.

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 action and side effect, then dense enum listings with no filler. The telegraphic style is efficient, though a few cells (formula meanings, source) are compressed to the point of ambiguity.

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 an 8-parameter tool with no output schema and no annotations, the return format and enum domains are covered, which is the critical part. Still missing are what 'source' values are valid, what happens to previously written silver data on re-fetch, and behavior on invalid series codes.

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

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

With 0% schema coverage this is the description's main job, and it delivers the enum domains for freq (D,B,W,SM,M,Q,S,A), agg (avg,min,max,first,last,sum), formula (0/1/3) and the date format YYYY-AA-GG. It leaves 'series' format, 'source' alternatives, and 'max_rows' only implicitly defined ('last max_rows rows').

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 ('Serileri çeker') and adds a concrete side effect ('yerel silver katmanına yazar'), which is more than a name restatement. It doesn't name the sibling it complements, but the fetch-vs-discover split against discover_series is inferable.

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

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

Usage is only implied: an agent can guess this is the step after discover_series, but the description never states when to call it, prerequisites, or what to do when a series code is unknown. No alternatives or exclusions are given.

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 of behavioral disclosure and does not meet it. It does not say whether the check makes live network calls to adapters (potentially slow or rate-limited), whether it is read-only, what constitutes pass/fail, or what happens when a source is unreachable. The output schema covers the return shape, but the operational character of the call remains unexplained.

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 clause that labels the tool type ('Kanarya testleri') before the specifics. There is no padding, though the brevity is partly the cause of the missing parameter and usage guidance rather than a virtue in itself.

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 output schema means return values need not be described, and the core intent is conveyed. However, for a diagnostic tool with an undocumented optional filter and no annotations, the description leaves the agent unable to predict cost, side effects, or how 'source' affects the check. Adequate as a minimum-viable definition, not sufficient for confident 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 0% for the single parameter 'source', which is optional with a null default, so the description must compensate and does not mention it at all. An agent cannot tell whether 'source' narrows the canary check to one adapter, names an adapter identifier, or accepts a URL. This is the most consequential gap: a wrong value here likely yields a misleading 'healthy' result.

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 check: canary tests verifying that adapters can pull the latest observations from critical series. This is a specific activity that distinguishes it from sibling data-access tools like fetch_series or discover_series, though it never explicitly contrasts itself with them. The generic name 'health' is rescued by the description, but the connection between 'health' and 'canary test of adapters' requires the reader to bridge it.

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

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

There is no statement of when an agent should call this versus fetch_series or list_sources, no prerequisites, and no exclusions. An agent can infer it is a diagnostic/validation call, but nothing confirms that inference or tells it what to do with a failing result. No alternatives are mentioned.

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; 'listeler' implies a safe read with no side effects, and it discloses the return shape (id, ad). However, it says nothing about ordering, whether the list is complete or paginated, or any authentication/permission requirements.

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 with no filler, front-loading the action and resource plus the returned fields. Every word 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 zero parameters and an output schema present, the description needn't explain returns or arguments, yet it still names the returned fields. It is nearly complete for such a simple tool; only the absence of any usage hint for picking it over list_sources leaves a small 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 there is nothing for the description to clarify; baseline 4 applies. The description correctly adds no parameter noise.

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 ('listeler' / lists sectors) and even names the returned fields (id, ad), so an agent knows exactly what it retrieves. It does not explicitly distinguish itself from the sibling list_sources, but the resource noun ('sektörler') is distinct enough to separate the two.

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

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

There is no statement of when to use this tool, no prerequisites, and no mention of alternatives such as list_sources. Usage is only inferable from the fact that it is a lookup of sector ids.

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 conditional filtering behavior, but says nothing about ordering, pagination, or whether the full catalog is returned when sector is omitted — only the existence of an output schema offsets this.

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

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

One compact sentence with the resource front-loaded and the conditional qualifier second — no filler. It is arguably too terse rather than too long.

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?

An output schema exists, so return shape needn't be described, and this is a simple one-parameter read. However, nothing defines what a 'source' is or how it relates to the sector values exposed by list_sectors, leaving a real gap for an agent wiring these calls together.

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 0%, so the description must compensate for the single 'sector' parameter. It does explain the parameter's effect (restrict results to sources related to that sector) and that it is optional, but adds no format, case-sensitivity, or valid-value 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?

Names a specific verb ('listeler') and resource ('kaynak kataloğunu'), so the agent knows this returns a catalog of sources. It doesn't explicitly contrast itself with the sibling list_sectors, but the resource is distinct enough to be separable.

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 the filtering use case ('sector verilirse o sektörle ilgili kaynaklar') but never states when to call this versus list_sectors or discover_series, nor any prerequisites for obtaining a valid sector value.

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 supplied, so the description carries the full burden; it does disclose the output format (markdown) and the content composition of the map, which is genuine value. However, it says nothing about whether valid sectors are validated, what happens for an unknown sector, or whether the call has any side effects – gaps that matter with zero annotation coverage.

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 dense sentence with no filler, and the output format and payload are front-loaded. Slightly more structure (e.g. separating what it returns from what it takes) would earn a 5.

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?

An output schema exists, so return-value detail is not required, and the tool is a simple single-parameter read. Still, for an agent to call it correctly it needs the sector value domain and its relationship to list_sectors, neither of which is 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?

There is one required parameter with 0% schema description coverage, so the description must compensate. It only implies that 'sector' is the subject via the possessive 'bir sektörün' and gives no format, casing, or valid-value guidance; list_sectors might enumerate valid values but that link is not stated.

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 pairs a specific verb ('döner' – returns) with a specific resource ('veri kaynağı haritası') and enumerates the contents: sources, macro features, market share, as markdown. An agent immediately knows what the tool produces. It stops short of naming a sibling it is distinct from, so it is not a 5.

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

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

There is no guidance on when to call show_map versus list_sources, build_panel, or discover_series, nor any mention of prerequisites or exclusions. The agent must infer the use case purely from the noun.

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