GCC Brokers

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds that this is static reference data (deposit/spread/leverage figures) but says nothing about freshness, caching, or whether values are locale- or regulation-dependent.

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 no filler, front-loaded with the resource and then the returned fields. It is a sentence fragment rather than a complete statement of action, but nothing is wasted.

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

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

No output schema exists, so the description carries the return-value burden — and it does so by enumerating the fields the caller will receive. For a low-complexity, read-only, single-parameter reference lookup, this is close to sufficient; only freshness/locale caveats are 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?

There is a single parameter with 100% schema description coverage, including a fully enumerated language list and a documented default of 'en'. The description contributes nothing about the language parameter, so the schema carries the full burden — the expected baseline of 3.

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 resource (GCC Brokers live account types) and enumerates the exact data returned: minimum deposit, spreads, commission, maximum leverage and stop-out level. It lacks an explicit verb, but the resource is unambiguous and none of the siblings (get_company_info, get_prices, list_instruments) overlap with account-type reference data.

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 alternatives, nor any prerequisites or exclusions. The usage is only inferable from the name and resource, so the agent gets no explicit 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the useful fact that the response is a curated set of company/regulatory pages rather than raw data, but says nothing about caching, freshness, or that no authentication is required. Adequate given the annotation coverage, but not 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?

A single front-loaded sentence opening with the subject ('Who GCC Brokers is') followed by a colon-delimited content list. No filler or repetition, though the comma-separated enumeration is dense and would read slightly better as a bulleted scope list.

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

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

With one enum parameter, no nested objects, no output schema and read-only annotations, the description is nearly sufficient: it tells the agent exactly which topics the payload covers. The only gap is that it does not state the return shape (e.g. page links vs. prose) or that output follows the requested language, which for a no-output-schema tool is a minor omission.

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 'language' parameter with 100% schema description coverage, including the full enum list and default, so the schema does the heavy lifting. The description never mentions the language parameter or that output text and links are localized, so it adds nothing beyond the schema. Per the high-coverage rule, baseline 3 applies.

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

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

The description names the resource (GCC Brokers company/regulatory information) and enumerates the specific content returned: legal entity, regulator, licence number with register link, Dubai office, execution model, client protections and contacts. That is far more specific than a restatement of the name, and the sibling set (prices, instruments, calendar, insights) makes the scope unambiguous in practice, even though no sibling is named explicitly.

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

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

Usage is implied rather than stated: an agent can infer this is the tool for entity/regulation/contact questions, but there is no explicit 'use this when...' clause, no exclusion of alternatives, and no mention of what it does not cover (e.g. account types or product terms). No guidance is wrong, but none is supplied either.

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 read-only, idempotent, non-destructive and closed-world, covering the safety profile. The description adds useful behavioral context by stating the default time window and default importance filter, but nothing about pagination, result caps, or ordering.

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, front-loaded with the resource and contents before the default-scope caveat. No filler, though it conflates return fields with scope in a single run-on sentence.

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 read-only lookup with no output schema, the description helpfully enumerates the returned fields (UTC time, currency, forecast, previous, actual) and states the default filter. An agent has enough to call it correctly; only ordering and result limits are unaddressed.

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 five parameters are fully documented in the schema. The description restates the from/to defaults and the UTC convention, adding little beyond what the schema already carries; baseline 3 applies.

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

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

Names a concrete resource (scheduled macroeconomic releases) with illustrative content (CPI, payrolls, central-bank decisions, PMIs) and the fields returned. It stops short of differentiating from siblings, though the sibling set (prices, instruments, insights) makes overlap unlikely.

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 default window ('next 7 days at medium and high importance') implies typical usage, so an agent can infer the no-argument case. There is no explicit when-to-use/when-not statement or mention of alternatives.

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 this a read-only, idempotent, non-destructive, closed-world lookup, so the safety profile is covered. The description adds genuinely useful context beyond that: results are specific to the Standard account, trading hours are normalized to UTC, and swap figures are split long/short with multi-night rollover days. It does not say how unknown or ambiguous instrument names 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?

Two sentences, zero waste. The returned-field inventory is front-loaded, and with no output schema present every enumerated field earns its place by telling the agent what it will receive.

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

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

No output schema exists, so the description must carry the return-value burden — and it does by naming the spec fields and their units (UTC hours). Account scope, alias acceptance, and the language parameter (fully documented in the schema) are all covered; nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description goes further by listing accepted alias forms ('EUR/USD', 'XAUUSD', 'gold', 'Nasdaq', 'bitcoin') that the schema's own examples ('EURUSD', 'gold', 'US30') do not cover. This materially reduces the chance of a failed lookup due to formatting.

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 (trading specifications for ONE instrument) and enumerates exactly what is returned: contract size, lot min/max/step, margin, swap long/short, rollover days, weekly hours in UTC. The singular scope cleanly separates it from the sibling list_instruments.

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 'one instrument' scoping implicitly routes the agent here for a single-symbol lookup rather than a catalog listing, and 'as clients trade it on the Standard account' establishes the account context. It never names an alternative tool or states a when-not condition, so it falls short of 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety and idempotency are covered. The description adds valuable non-obvious behavior: streaming source (Standard account), UTC timezone, and the stale-quote fallback outside trading hours marked as not live. That is exactly the kind of context structured fields do not carry.

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 no filler, front-loading the core output and following with the important off-hours caveat. Every clause informs correct invocation or interpretation.

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

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

For a simple two-parameter read-only lookup with a complete schema and no output schema, the description supplies the account scope, timezone, and stale-data marker. It omits return-value structure, though the tool has no output schema, so some ambiguity remains about the exact response shape.

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

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

Schema coverage is 100%, so the schema documents both parameters thoroughly, including instrument examples and the language enum. The description adds only the 'up to 10' limit, which the schema already enforces via maxItems. Baseline 3 is appropriate.

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

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

The description clearly states a specific verb+resource: 'Latest bid and ask quotes for up to 10 GCC Brokers instruments', and adds context about the account type and quote time. It is unambiguous what the tool returns.

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 tool versus alternatives such as list_instruments or get_instrument. The description implies a market-data lookup but does not state when an agent should call it or what it should not be used for.

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 the safe read-only, idempotent, non-open-world profile, and the description adds genuinely new behavioral context: result ordering (newest first) and the shape of each returned item (title, summary, date, link). It does not mention pagination or the 20-item cap, so it falls short of full disclosure.

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 sentence that front-loads what the tool returns and appends the optional filter; every clause carries information and there is no padding.

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 usefully enumerates the returned fields and ordering, and the filter behavior is covered. Missing only limit/pagination behavior, which is a minor gap for a simple list tool.

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

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

Schema coverage is 67% and both query and language are already well documented in the schema. The description restates the query filter semantics without adding anything new and never mentions the limit parameter at all, so it only meets the baseline.

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 the specific resource (market analysis articles published by GCC Brokers), the ordering (newest first), and the returned fields, so an agent can distinguish it immediately from the price/instrument/calendar siblings.

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

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

The optional title/summary filter is described, which implies when to pass a query, but there is no guidance on when to choose this tool over siblings such as get_economic_calendar or when not to use it.

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 and destructiveHint=false, so safety is covered. The description adds value beyond them by disclosing the payload shape — each instrument ships with its gccbrokers.com page link — which matters since there is 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?

A single front-loaded sentence names the resource and its contents, followed by a short filtering clause. No filler, though the parenthetical category list partly duplicates the enum already in the schema.

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 read-only listing tool whose annotations cover the safety profile and whose schema fully documents both parameters, the description supplies the return contents and the category filter. Nothing critical is missing, though a pointer to get_instrument for single lookups would close the last 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 coverage is 100% with both parameters enumerated and documented (category enum, language enum with default en). The description only echoes the category filter, adding no format or behavior beyond what the schema already states, so the baseline 3 applies.

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

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

Specific verb ('Lists') plus resource ('instruments GCC Brokers offers') and an explicit enumeration of the asset classes covered, so the agent knows exactly what comes back. It does not, however, distinguish itself from the singular sibling get_instrument, leaving that routing to be inferred.

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?

'Filter by category' implies how to narrow results, but there is no statement of when to call this versus get_instrument or get_prices, and no exclusions or prerequisites. Usage is implied rather than taught.

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