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

No annotations are supplied, so the description carries the full behavioral burden, yet it only names the returned content. It says nothing about read-only semantics (implied but unstated), authentication, rate limits, or failure behavior when a framework_id is unknown.

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

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

Two short, front-loaded sentences with no filler, and the resource attribute list leads. The bilingual duplication adds length without adding information for a non-Turkic reader, which is the only minor cost.

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 lookup with no output schema and no annotations, the description gives the source and a rough sense of the return, which is roughly adequate. It still leaves the identifier's origin and the shape of the returned act details unspecified, so it is minimum-viable rather than 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 0% and the description never explains the single required parameter framework_id — not its meaning, format, or where to obtain it. With one undocumented parameter, the description fails to compensate for the schema gap.

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 resource (a legal act) and the attributes returned (details and legal status) from a named source (e-qanun.az), so the agent knows this fetches an act record. It does not explicitly differentiate itself from the sub-unit siblings (eqanun_madde, eqanun_bend) or the search sibling (eqanun_axtar), which keeps it below a 5.

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

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

There is no when-to-use guidance and no routing to alternatives, even though the sibling set contains near-collisions (article, clause, search). Usage is only weakly implied by the tool name, and an agent could easily confuse it with eqanun_madde or eqanun_bend.

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 entire behavioral burden, yet it discloses nothing about matching semantics (substring vs whole word, case/diacritics), the result shape, or whether results are paginated. It implies a read-only lookup but never states it.

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 purpose, which is good. However, the Azerbaijani line is a literal translation that repeats the same information without adding anything for an English-reading agent, so not every sentence 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 search tool with no output schema and no parameter documentation, the description should at least state what comes back (matching articles/snippets) and how matching works. Neither is present, leaving the agent guessing about results and the scope parameter.

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% for two required parameters. The description echoes 'soz' (word) as 'a word' but never explains framework_id — the parameter that identifies which act to search — nor how the word is matched against article text.

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 — finding articles of an act that contain a word — which is clear enough to act on. It does not, however, distinguish itself from search-like siblings such as president_axtar or how it differs from the structural siblings eqanun_akt/eqanun_madde/eqanun_bend.

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

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

No when-to-use or when-not-to-use guidance is given, and no alternative is named. The only hint is the implied 'search inside one act's articles' scope, which the agent must infer from the phrasing.

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 full burden. It discloses only that output is 'verbatim text', implying a read operation, but says nothing about permissions, what happens when the clause or framework_id is invalid, rate limits, or the response shape. For an un-annotated tool this is a significant gap.

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

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

Very short and front-loaded, with the core purpose in the first phrase. The English/Azerbaijani duplication adds redundancy for a monolingual agent but costs little space.

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 retrieval tool with no annotations and no output schema, the description should explain the framework_id/bend identifier scheme and error behavior. It leaves the agent unable to construct a valid call with confidence beyond the parameter names.

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 both parameters are undocumented in structured form. The description clarifies that 'bend' means a numbered clause, adding modest meaning to that parameter, but says nothing about 'framework_id' (apparently the parent act identifier), its expected values, or the expected format of the bend identifier (e.g., '5.2' vs '5').

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 (retrieves verbatim text) and a precise resource (a numbered clause/bənd within Cabinet or Presidential acts), which implicitly distinguishes it from siblings like eqanun_madde (article) and eqanun_akt (act). It does not explicitly name those siblings, so an agent must infer the granularity distinction from terminology alone.

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 use this tool versus eqanun_madde, eqanun_akt, or the *_axtar search siblings. The agent must guess whether 'bənd' retrieval is a lookup by ID or a broader query. No prerequisites or context conditions are 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?

No annotations are supplied, so the description carries the full behavioral burden. It does add one genuinely useful trait — the text is 'verbatim' and 'in-force', implying repealed or historical versions are unavailable — but says nothing about failure modes for invalid framework_id/madde or output shape.

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 operation and its key constraint. The bilingual Azerbaijani restatement duplicates the English content rather than adding information, which is mild redundancy but not bloat.

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 annotations, no output schema, and 0% parameter coverage, the description is too thin for a 2-parameter required-input tool. It omits where framework_id comes from and what the returned text includes, leaving the agent to guess at invocation mechanics.

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 both parameters. It clarifies 'madde' as the article identifier, but gives no explanation of 'framework_id' (presumably the act's ID, perhaps from eqanun_akt), leaving half the parameter semantics 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 verb and resource: returns the verbatim, currently in-force text of a single article (Maddə) of an act. This implicitly separates it from eqanun_akt (whole act) and eqanun_bend (sub-article clause), though those siblings are never named outright.

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

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

No when-to-use guidance and no routing to alternatives. The agent is left to infer that this is the lookup to use once a framework and article number are already known, versus eqanun_axtar for discovery.

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, and it says almost nothing beyond 'clean text'. It does not disclose whether the URL must be on mfa.gov.az, whether it fetches live pages, what happens with non-article URLs, or how large pages are handled.

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

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

It is short and front-loaded, which is good, but it is fully duplicated in two languages rather than using the second line to add information. The bilingual restatement consumes half the text without adding value.

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

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

For a one-parameter tool with no output schema, the definition is minimal but the gist (returns cleaned page text) is inferable. Missing are the domain expectation for the URL and any notion of what the returned text looks like, which matters since there is no output schema to fall back on.

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 `url` parameter. The phrase 'of a mfa.gov.az page' faintly implies the URL must belong to that domain, which adds a little meaning, but no format, protocol, or validation expectations are given.

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 operation (cleaning/extracting text) and the exact resource scope (a mfa.gov.az page), so the agent knows the domain constraint. It is distinguishable from siblings like president_metn and the eqanun_* tools by the explicit mfa.gov.az target, though it never states the operation in terms of an action verb like 'fetch' or 'extract'.

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 use this tool versus the sibling search/extraction tools (president_metn, president_axtar, eqanun_metn-equivalents). No prerequisites, no exclusions, and no statement of what conditions select this tool over a search variant.

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, yet it discloses almost nothing: no indication of what happens on an unrecognized input, no return format, and no clarification of how 'full and short form' are delivered. Only the underlying data source is mentioned.

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 definition is short and front-loads the English statement before the Azerbaijani mirror. The bilingual duplication is mild redundancy but costs little and the entry is not bloated.

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?

A one-parameter lookup with no annotations and no output schema needs the description to explain input format and expected return; neither is present. The definition is too thin for an agent to call it 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 description coverage is 0% for the single required parameter 'ad', and the description does not compensate — it never says whether 'ad' expects a country name in Azerbaijani, English, or a code, nor whether it is exact-match. The one parameter is effectively 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?

The description identifies the resource (the official Azerbaijani name of a state) and its scope (full and short form), but supplies no verb and does nothing to separate it from siblings like eqanun_akt or mfa_metn. An agent can guess it is a lookup, but the purpose is only implied.

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

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

There is no when-to-use guidance, no prerequisites, and no named alternative among the eight sibling tools. The parenthetical '(mfa.gov.az əsaslı yerli siyahı)' hints at the data source but says nothing about when this tool should be chosen.

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 behavioral burden but discloses almost nothing: no return format, pagination, rate limits, or whether it only covers titles/links vs full content. It does hint at scope (official titles and document links), which is its only added context.

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

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

The description is a compact single line in two languages, front-loading the core purpose. The bilingual repetition is slightly redundant but brief and unlikely to confuse an agent.

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 search tool with no annotations, no output schema, and an undocumented parameter, the description is too thin. It omits query semantics, result format, and scope limits relative to siblings, so it is not sufficient for reliable 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% and the single required parameter 'soz' has no description anywhere. The description does not explain that 'soz' is the search query (likely Azerbaijani for 'word'), so the agent gets no semantic guidance beyond the parameter name.

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 (search) and resource (president.az) and names what it returns (official titles and document links). It does not, however, differentiate itself from siblings like president_metn or the eqanun_* tools, so it falls short of a 5.

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

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

No when-to-use guidance is given. It does not explain when to choose this tool over siblings like president_metn (presumably for full document text) or the eqanun_* legal tools, leaving the agent to infer the appropriate context.

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

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

No annotations are provided, so the description carries the full behavioral burden. It hints that the page is stripped to 'clean text' but says nothing about return format, error handling for non-president.az URLs, rate limits, or whether the fetched page must already exist.

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?

Very short and front-loaded, with no filler. The bilingual restatement is duplicative for a single reader but defensible for a multilingual audience.

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 fetch tool with no output schema and no annotations, the description conveys the core operation but omits the return shape and any failure conditions. Minimally adequate rather than 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 0% and the single 'url' parameter is undocumented. The description only weakly constrains it by naming president.az, without stating that the URL must belong to that domain or what format it expects.

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 ('clean text') and resource ('president.az page'), so an agent can tell it extracts page text rather than searching. It does not explicitly distinguish itself from the sibling president_axtar, which is a search tool, leaving the boundary 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?

No guidance on when to use this versus president_axtar or the other *_metn siblings. The agent must infer that this is the fetch-a-known-URL tool from the name and parameter alone.

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