Loading ToolBench
Agent-native halal (Sharia) stock screening. Wraps the public HalalStock API to check whether a stock or ETF is Sharia-compliant, screen portfolios, and search tickers across US, Gulf, and global markets based on AAOIFI Standard 21.
Three tools with clear, domain-specific purposes and well-structured schemas. Naming follows verb_noun convention (check_halal, screen_portfolio, search_stocks). Descriptions are substantive (150-250 chars) and explain WHAT, WHEN, and WHAT-RETURNS. All parameters have types and descriptions. However, output schemas are not formally documented, responses are inferred from API behavior rather than explicitly declared. Error handling is minimal (generic HTTP error wrapping). No input validation guidance (e.g., symbol format constraints, profile enum enforcement). Missing tool annotations (readOnlyHint, idempotentHint). Baseline: avg tool description ~194 chars (these are 180-220 chars, good); avg params ~4 (these have 2-3, good); 100% of A+ tools document return types (this server does not).
Check whether a stock or ETF is Sharia-compliant (halal). Args: symbol: Ticker. US tickers are plain (e.g. "AAPL"). Saudi/Tadawul uses a .SR suffix (e.g. "2222.SR" = Saudi Aramco); other markets use their Yahoo-style suffix (e.g. "DIB.AE", "ASML.AS"). ETFs work too. profile: "standard" (core scholarly consensus) or "strict" (also excludes debated activities like conventional hotels/entertainment). Returns the verdict (halal / not_halal / questionable), a 0-100 compliance score, the AAOIFI financial ratios, a confidence level, any corroborating Sharia-screened funds, and a plain-language explanation.
Screen several stocks/ETFs at once for Sharia compliance. Args: symbols: List of tickers, e.g. ["AAPL", "2222.SR", "JPM"]. Up to 25. profile: "standard" or "strict". Returns each symbol's verdict and score plus a summary count.
Search for a stock or ETF by company name or ticker. Args: query: e.g. "apple", "aramco", "halal etf". limit: max results (default 8). Returns matching symbols with names and types (stock/etf) to feed into check_halal.
Output schemas not formally documented. Responses are inferred from API behavior (dict return type visible in code) but no structured schema definition provided to LLM. LLMs cannot plan downstream tool calls or extract fields reliably without knowing response structure.
No input validation or constraint documentation. 'profile' parameter accepts 'standard' or 'strict' but no enum constraint declared. 'symbol' format varies by market (US plain, .SR suffix, Yahoo-style) but no regex or format guidance. LLMs may pass invalid values.
Error handling is generic and non-actionable. _get() returns {'error': 'HTTP 404', 'detail': '...'} with no recovery guidance. LLM cannot determine if error is retryable, user-fixable, or fatal. No suggestions for alternative actions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
No tool annotations (readOnlyHint, idempotentHint). All three tools are read-only and idempotent, but this is not declared. LLMs cannot infer safety properties and may incorrectly reason about retry behavior or side effects.
screen_portfolio accepts up to 25 symbols but no pagination or result limit enforcement documented. If API returns all 25 results with full details, response could be large. No guidance on result structure or truncation.