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 two genuinely useful behavioral facts: the rate limit (~50 requests/minute) and the semantics of thinking=true. However it says nothing about whether the call is stateless, how multi-turn context is expected to be passed (there is no history parameter), or what latency/cost to expect for a 27B model.

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 core purpose and kept to four short sentences; the dialect list is the only slightly tangential material but it does inform model selection. No filler or restatement of the name.

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 and no output schema, the description is the only source of behavioral context, and it omits the shape of the response and how conversation state is handled across turns. Rate limit, default model, and the thinking flag are covered, which makes it adequate but leaving real gaps for a 6-parameter 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 description coverage is 0%, so the description must compensate. It usefully explains the non-obvious parameters — model defaults to Fanar-C-2-27B with "Fanar" as alias, and thinking toggles step-by-step reasoning — but is silent on prompt, system, max_tokens, and temperature. Those four have conventional LLM semantics, which keeps this above a floor score but well short of full coverage.

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 ("Chat with a Fanar language model") and names the concrete model plus its default alias, so an agent knows exactly what invocation does. It stops short of naming the siblings it is not — no signal that translate, poem, or islamic_qa exist for those jobs — so it does not differentiate from the family.

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 tells how to configure a call (thinking=true) but never says when this general chat tool is the right choice versus the ten specialized siblings such as fanar_translate, fanar_poem, or fanar_islamic_qa. No prerequisites, exclusions, or routing guidance 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 and does so well: it discloses async/latency behavior (quick 3-6, standard 7-10), a key prerequisite ('Requires Fanar-Sadiq-2 on the key'), and a rate limit ('About 20 jobs a day'). It does not cover failure/timeout handling or cost, keeping it out of 5 territory.

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 purpose, then timing, polling target, prerequisite, and quota, each in its own clause with no filler. The parenthetical latency figures are the densest part but they carry real information, so it stays efficient.

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 async job tool with no output schema, the description adequately covers the return shape (structured report with headings and cited sources) and the polling workflow. The main shortfall is the undocumented parameters (topic, web_search, comprehensive depth), which the schema also fails to explain.

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 it only partially does. It explains the depth enum indirectly by giving latency for 'quick' and 'standard' (leaving 'comprehensive' unexplained) but says nothing about the 'topic' or 'web_search' parameters, leaving two of three 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: 'Start a Fanar-Sadiq-2 deep research job' producing 'a structured report on an Islamic topic, with headings and cited sources.' It also names the sibling it hands off to (fanar_deep_research_result), so an agent can distinguish it from fanar_islamic_qa and fanar_chat 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?

Gives clear operating context: it is an async job taking minutes, and the agent should 'poll it with fanar_deep_research_result.' This tells the agent both when to reach for it and how to follow up. It stops short of explicit when-not guidance (e.g. preferring fanar_islamic_qa for quick single questions), so it is not 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, the description carries the full behavioral burden. It usefully signals this is a read operation whose return varies by job state (status, progress, or finished report), which is real behavioral information. It says nothing about authentication needs, error behavior for an unknown/expired job_id, or result retention/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?

One sentence, front-loaded with the verb and the three possible return states; no filler or redundancy.

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

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

With no output schema and no annotations, the description does cover the variable nature of the response, which is the useful part. However, for a polling tool it omits the critical operational context: how to obtain job_id and how to interpret a still-in-progress versus completed response.

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 single parameter job_id has 0% schema description coverage, so the schema provides no semantics at all. The description mentions 'deep research job' but never says where the job_id originates (presumably the fanar_deep_research response) or what shape it takes, so it does not compensate for the coverage 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?

Names a specific verb (Fetch) and a specific resource (status, progress or finished report of a deep research job), and even identifies the underlying engine (Fanar-Sadiq-2). It does not explicitly contrast itself with the sibling fanar_deep_research (which starts a job), but the verb/resource pairing makes the retrieval role clear.

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 infer this is called after fanar_deep_research to poll or collect results. There is no explicit when-to-use, no statement that the job_id comes from fanar_deep_research's response, and no guidance on polling cadence or when the result is final versus still running.

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 it does disclose real behavior: the image is persisted to disk, the return contains a file path plus Fanar's revised prompt, and there is a ~20 requests/day rate limit. It omits other behavioral facts an agent needs, such as whether an existing file is overwritten when 'filename' is supplied, latency/cost, or any auth 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?

Two short clauses plus a rate limit, with the action and its side effect front-loaded and the return contract immediately after. Every sentence carries information; nothing is padded.

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 description usefully covers the return contract in the absence of an output schema and flags the rate limit, but with no annotations and 0% schema coverage it leaves the optional 'filename' behavior and overwrite semantics undocumented. Adequate but with a clear parameter-side gap.

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

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

Schema description coverage is 0% across 3 parameters, so the description must compensate and largely does not. It hints at 'prompt' and at revision ('the prompt as Fanar revised it', which relates to the 'revise' flag), but the optional 'filename' parameter is never mentioned, so the agent has no idea what supplying it does.

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 ('Generate a culturally aware image with Fanar Oryx'), adds the side effect ('and save it'), and names what comes back ('the file path and the prompt as Fanar revised it'). It is the only image-generation tool among siblings that are all text/speech/QA tools, so the agent can route to it unambiguously.

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 verb (generate an image) and no alternatives exist among the siblings, but the description never states when to prefer it, when not to use it, or any prerequisite (e.g., whether a model must be selected first). The rate-limit note ('About 20 requests a day') is useful planning context but is not usage guidance per se.

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 discloses several non-obvious traits: answers must be presented with citations, never as a fatwa, madhab/source filters require key entitlement, and throughput is ~50 requests/minute. It omits auth/permission details beyond entitlement and says nothing about the response shape, but the behavioral context is substantially richer than the schema alone.

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 tight sentences with the core action front-loaded, followed by presentation rules and operational limits. Dense but every sentence carries information; only the rate-limit sentence sits a bit awkwardly at the end without a heading.

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 annotations, no output schema, and 7 parameters at 0% schema coverage make this a high-burden case. The description covers purpose, presentation ethics, and rate limits, but leaves return-format expectations and several parameter semantics undocumented, so an agent still has gaps before invoking 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 description coverage is 0% across 7 parameters, so the description must compensate. It adds meaning for model (Fanar-Sadiq-2), madhab, and preferred/excluded sources via the 'madhab and source filters' clause, but leaves max_tokens, restrict_to_islamic, and question's semantics entirely unexplained, covering only about half the parameters.

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 ('Ask Fanar-Sadiq an Islamic question and get an answer grounded in cited sources'), which distinguishes it from generic siblings like fanar_chat and fanar_deep_research. It also names the model tier (Fanar-Sadiq-2) and its added filtering capability, so an agent can differentiate the tool without opening the schema.

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

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

Gives clear operating context: use it for Islamic questions, show references with the answer, and present results as a cited answer rather than a fatwa. It does not explicitly name an alternative sibling (e.g. fanar_chat) or state when not to use it, so it stops short of full 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?

No annotations are provided, so the description carries the full disclosure burden. It does add genuinely non-obvious context — entitlements vary per key and some models (Fanar-Sadiq-2) must be enabled by Fanar — but it says nothing about the return shape, ordering, or whether the list can change over time, which matters for a discovery endpoint 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 sentences, front-loaded with the core action, followed by the one caveat an agent actually needs. Nothing is padded or redundant.

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 discovery tool with no annotations or output schema, the definition covers the essential question (which models are callable by this key) and the key gotcha (per-key entitlements). The only shortfall is that it never hints at what the returned list contains, which the absent output schema would otherwise have to carry.

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 schema-side baseline is 4. The description appropriately adds no parameter detail because there is nothing to parameterize, and correctly frames the scoping as implicit via the API key rather than a request field.

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

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

States a specific verb and resource ('List the Fanar models this API key may call') with an explicit scoping qualifier ('this API key'), which is unambiguous against discovery-style siblings like fanar_chat or fanar_validate_quotations. The mention of Fanar-Sadiq-2 powering the quotation validator and deep research further situates it relative to the other 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 only implied: the entitlement note hints you call this to discover what your key can access, but there is no explicit when-to-use, when-not-to-use, or named alternative. No prerequisites (e.g., must be called before choosing a model) are spelled out.

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 it does disclose the model prerequisite and the bilingual scope. However, it never says what the scoring produces (scale, categories, whether all content is judged or only flagged content), which matters for a judge/scoring 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 tight sentences with zero filler; the core action and the language scope come first, the prerequisite last. 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?

No output schema and no annotations exist, yet the description never characterizes the returned score/thresholds, which is the primary thing a caller needs in order to use the result. The input side is adequately covered for a two-parameter 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 description coverage is 0%, so the description must compensate; it identifies the two inputs semantically as a prompt/response pair, which is genuinely useful mapping. It adds no further detail such as size limits, language-per-field expectations, or whether the response must come from a specific model.

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 (Score), a specific resource (prompt and response pair), the engine (FanarGuard) and the scoring dimensions (safety, cultural awareness). It is unmistakably different from the chat/translate/QA siblings, though it does not name an alternative to route away from.

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 use case (safety and cultural moderation of an exchange) and gives one concrete prerequisite: Fanar-Guard-2 must be on the key. There is no explicit when-not guidance or pointer to a sibling to use instead.

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 usefully discloses a prerequisite ('Requires Fanar-Diwan on the key'), which is real context beyond the schema, but says nothing about output format, length, streaming, or failure behavior for a generative tool.

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 core action, with no filler. It is appropriately sized, though the second sentence reads as a prerequisite note rather than description.

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 generative tool with no annotations, no output schema, and an undocumented prompt parameter, the description leaves too much unstated: no return-value expectations, no prompt guidance, and no usage context beyond the model requirement.

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 single 'prompt' parameter has 0% schema description coverage and the description adds no guidance on what the prompt should contain (theme, meter, length, style). An agent gets no help constructing a valid input.

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 ('Compose') and resource ('Arabic poetry in the classical tradition'), which clearly distinguishes it from generic siblings like fanar_chat or fanar_translate. It names the backing model (Fanar-Diwan) but does not explicitly contrast against alternative 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?

There is no guidance on when to choose this tool over fanar_chat for poetry, nor any exclusions or prerequisites beyond the model requirement. Usage is only implied by the description of what it produces.

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 on output: it saves to a file and returns the file path. It also discloses a rate limit (~20 requests/day) and a model precondition. It omits permission/auth needs, whether files persist or are overwritten, and text-length 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 dense sentences, front-loaded with the core action and output artifact, followed by the model caveat and quota. Little waste. The trailing 'About 20 requests a day' is terse and slightly ambiguous as to whether it is a hard cap or a soft guideline.

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 6-parameter tool with no annotations, no output schema, and 0% schema descriptions, the coverage of output form and rate limits is helpful but leaves voice/language pairing, format selection, and file-naming behavior undocumented anywhere. Adequate, 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 0% across 6 parameters, so the description must compensate and only partially does. It explains the model enum values and hints at quran_reciter, but says nothing about the 10-value voice enum (which voices suit Arabic vs English), filename, or response_format.

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: synthesize Arabic/English text into an audio file and return the path. That is unambiguous and clearly distinct from siblings like fanar_transcribe (the inverse) or fanar_chat. It stops short of naming an alternative sibling or contrasting explicitly, so it is not quite 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 a concrete routing condition: Qur'an recitation by a named reciter requires Fanar-Sadiq-TTS-1, implying Fanar-Aura-TTS-2 otherwise. It also surfaces a practical quota (~20 requests/day). No explicit when-not or alternative-tool guidance, but the model-selection rule is real, actionable 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses quota limits (~10/day with long_form, ~20/day otherwise) and the model switch, which an agent needs for planning. It still omits accepted audio formats, length/size limits for the short-form path, and any error or failure behavior, leaving meaningful 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 tightly written sentences with zero filler; the core purpose is front-loaded and the quota/model trade-off follows immediately. 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 3-param tool with no annotations and no output schema, the description covers purpose, model choice, and quotas adequately. It does not describe what each output format returns or the supported audio inputs, which an agent choosing between text/srt/json would want. Adequate but with clear 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?

Schema description coverage is 0%, so the description must compensate. It well explains long_form (which model it selects and the rate-limit consequence), which is the least obvious parameter. It says nothing about output (text/srt/json) beyond what the enum conveys and nothing about audio_path format or constraints, so compensation is partial.

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 (Transcribe), resource (audio from a local file), and the languages supported (Arabic including dialects, or English), and names the backing model (Fanar Aura). No sibling does the same thing — fanar_text_to_speech is the reverse direction and fanar_translate is text-only — so an agent can select this without ambiguity.

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 long_form sentence gives an implicit decision rule (use long_form for long audio, at the cost of fewer daily requests), which is genuine usage guidance. However, it never states when to prefer this over fanar_text_to_speech or fanar_translate, nor any prerequisites for the tool itself. Usage is implied rather than 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 are provided, so the description carries the full burden, and it does disclose genuinely useful operational traits: a ~20 requests/day quota and a ~4,000-word per-request limit. It stops short of describing return format, error behavior, or latency, and no output schema exists to cover that 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?

Two tight sentences that front-load the capability statement and then the operational limits. Every clause carries information; nothing is restated from the name.

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 four-parameter tool with zero schema description coverage, no annotations, and no output schema, the description should document the model and preprocessing choices and say something about the returned translation. It covers quotas and text length but leaves the parameter surface entirely unexplained.

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 four parameters, three of which are enums, so the schema offers no semantic help either. The description mentions the language pair only implicitly ('between Arabic and English') and says nothing about the model enum options or the preprocessing modes (preserve_html, preserve_whitespace, etc.), leaving the agent to guess.

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 (Translate) and resource (text between Arabic and English) plus the underlying model family, and adds a distinguishing scope note about classical Arabic (hadith, fiqh). This clearly separates it from siblings like fanar_chat, fanar_islamic_qa, and fanar_poem.

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 intended use case (Arabic/English translation, including classical religious texts) and gives operating constraints, but never states when to prefer this over fanar_chat or other siblings, nor any exclusions or prerequisites. Usage is inferable but not routed.

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 mostly succeeds: it discloses output semantics (verified quotations tagged and linked to canonical sources, untagged means unverified), a hard authentication dependency (requires Fanar-Sadiq-2 on the key), and a rate limit (~200 req/min). It does not state whether the operation is read-only or has side effects, which is the main remaining 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?

Front-loads the purpose, then output behavior, then operational constraints. Dense but each sentence carries distinct information; the auth and rate-limit details are the only parts that could arguably be trimmed for a simpler consumer.

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 must cover return behavior and it does (tagged/linked vs. untagged/unverified). It also covers the key requirement and rate limit. Only the read-only vs. mutating nature is left unstated, which is a minor omission for a validation 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?

There is a single 'text' parameter with 0% schema description coverage. The description compensates by clarifying the kinds of text accepted (LLM answer, draft, article), but adds no format, size, or encoding guidance beyond that.

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 compound verb (detect and verify) and a precise resource (Qur'an and hadith quotations) with the input domain spelled out. An agent can distinguish this from siblings like fanar_moderate or fanar_islamic_qa 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?

Gives concrete usage contexts (LLM answer, draft, article), making it clear when this tool applies. It stops short of naming when-not to use it or pointing to a sibling alternative, so it is a solid 4 rather than a 5.

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