foura-mcp

• foura_single

  554445A4.6

  This is an excellent description that clearly explains the tool's purpose, usage, and behavior, with explicit guidance on when to use alternatives. It adds significant value beyond the schema and annotations, covering complex aspects like validation and timeouts. The only minor improvement would be structuring the description for easier scanning, but it is already highly effective.

  5

  Purpose Clarity · 25%The description clearly states the tool sends one HTTP request and returns the response, with a specific verb and resource. It distinguishes itself from siblings by explicitly mentioning when to use foura_proxy and foura_browser, and the description covers the main use cases (static pages, JSON APIs, server-rendered HTML).

  5

  Usage Guidelines · 20%The description provides explicit guidance on when to use this tool versus alternatives: 'Switch to foura_proxy when the response is blocked or the exit country matters, and to foura_browser when the page needs JavaScript.' It also explains when to set browser/os/version and how to use proxy IDs, giving clear context for usage.

  4

  Behavioral Transparency · 20%The description adds significant behavioral context beyond the annotations: it explains the validate mechanism, nested timeouts, credit reporting, and plan_limit_ error handling. It also mentions that a refusal by the plan arrives as a plan_limit_ code with retryAfter, which is not in the annotations. The annotations already declare readOnlyHint=true and destructiveHint=false, so the description complements them well.

  4

  Parameter Semantics · 15%The schema has 100% coverage, so the baseline is 3. The description adds value by explaining the nesting of timeouts and the validate behavior, which is not fully captured in the schema. It also clarifies the proxy parameter's two forms and the unblocker's interaction with profile selection, going beyond the schema descriptions.

  4

  Conciseness & Structure · 10%The description is a single paragraph but covers many important aspects without excessive verbosity. It is front-loaded with the core purpose and then adds usage details. It could be slightly more structured (e.g., bullet points) but is still concise and every sentence adds value.

  5

  Contextual Completeness · 10%Given the tool's complexity (20 parameters, nested objects, output schema), the description is remarkably complete. It covers the main use cases, alternatives, validation, timeouts, authentication, and error handling. The output schema exists, so return values are not needed in the description. The description provides enough context for an agent to use the tool effectively.

  params

  20 (2 required, 100% described)

  annotations

  readOnly=true destructive=false openWorld=true

  output schema

  yes

  cost

  2

  bytes

  10897

  hash

  ac7aa8bda5d8caf2

• foura_proxy

  Shadowing Risk555445A4.8

  This is an exemplary tool description that excels in purpose clarity, usage guidance, and behavioral transparency, going far beyond the structured annotations. It effectively differentiates from siblings and provides critical operational details like rotation semantics, validation, and cost. The only minor weakness is the lack of structural formatting, but the content is comprehensive and highly actionable for an AI agent.

  5

  Purpose Clarity · 25%The description clearly states the tool routes HTTP requests through rotating proxies with retry, and explicitly distinguishes it from siblings by highlighting unique features like strict exit-country allowlist, named browser family per attempt, and premium exit escalation. It also names the sibling tool foura_browser for JavaScript-heavy pages, reinforcing differentiation.

  5

  Usage Guidelines · 20%The description provides explicit when-to-use guidance: 'Use it when foura_single is blocked, and whenever the exit itself matters' and 'Use foura_browser when the page needs JavaScript.' It also explains when not to use it (e.g., for JavaScript pages) and mentions cost implications ('Rotation costs several times a single request'), giving clear context for decision-making.

  5

  Behavioral Transparency · 20%The description goes well beyond the annotations (readOnlyHint, openWorldHint, destructiveHint) by detailing rotation behavior, retry logic, exit-country strictness, premium escalation as an allowance, timeout interactions, validation semantics, and the meaning of returned IDs. It also explains error handling (plan_limit_ codes) and cost reporting, providing rich behavioral context that annotations alone do not cover.

  4

  Parameter Semantics · 15%Schema coverage is 100%, so the baseline is 3. The description adds significant value by explaining the interplay between maxTries and timeout_ms, the meaning of exitClass as an allowance, the strictness of exitCountries (never falls back), and the purpose of validate in retry decisions. It also clarifies the returned exit id usage, which is not in the schema. Minor deduction because some parameter details (e.g., offload_large) are not elaborated in the description, but the schema already covers them.

  4

  Conciseness & Structure · 10%The description is dense and information-rich, but it is a single long paragraph that could benefit from structural breaks (e.g., bullet points or short paragraphs) to improve scannability. Every sentence adds value, but the length may reduce readability for an agent parsing quickly. Still, it is well-organized and front-loaded with the core purpose.

  5

  Contextual Completeness · 10%Given the tool's complexity (7 parameters, nested objects, output schema, and multiple sibling tools), the description covers all critical aspects: rotation behavior, validation, timeouts, exit selection, error handling, cost, and integration with other tools. The output schema exists, so return values are documented elsewhere, but the description adds essential context about attemptReport and exit id usage, making it complete for an agent to use effectively.

  params

  7 (1 required, 100% described)

  annotations

  readOnly=true destructive=false openWorld=true

  output schema

  yes

  cost

  5

  bytes

  14569

  hash

  577349d651a25cf4

• foura_browser

  554445A4.6

  This is an exemplary tool description that clearly defines the tool's purpose, provides explicit usage guidelines with alternatives, and adds significant behavioral context beyond annotations. It effectively compensates for the tool's complexity with detailed parameter semantics and completeness, making it highly actionable for an AI agent.

  5

  Purpose Clarity · 25%The description clearly states the tool loads a public URL in a full browser session with JavaScript and DOM rendering, distinguishing it from siblings by emphasizing full browser capabilities. It explicitly contrasts with foura_single and foura_proxy for simpler content, making the purpose and differentiation clear.

  5

  Usage Guidelines · 20%The description provides explicit guidance on when to use this tool (SPAs, lazy-loaded content, browser challenges) and when not to (prefer foura_single or foura_proxy for HTML content). It also instructs to call foura_proxy first for protected pages and to set unblocker:false for exact page loads, offering clear alternatives and exclusions.

  4

  Behavioral Transparency · 20%Annotations indicate readOnlyHint=true and destructiveHint=false, but the description adds valuable behavioral context: it is the most expensive and slowest tool, cookies come back with the response, and it can return error envelopes for checkStatus/checkText failures. It also mentions plan_limit_browser_daily for daily allowance, which is beyond annotations. Minor gap: no explicit mention of rate limits or concurrency, but overall strong.

  4

  Parameter Semantics · 15%Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining the proxy parameter's three forms (URL, base36 ID, omit) and the purpose of checkStatus/checkText as validation mechanisms. It also clarifies the offload_large behavior with resource_link, which is not fully in the schema. This extra context justifies a 4.

  4

  Conciseness & Structure · 10%The description is a single dense paragraph that front-loads the core purpose and then covers usage, alternatives, and error handling. It is efficient but slightly long; however, every sentence adds value, and the structure is logical. A 4 is appropriate for its density without being verbose.

  5

  Contextual Completeness · 10%Given the tool's complexity (10 params, nested objects, output schema), the description covers all critical aspects: when to use, alternatives, cost/performance, error handling, proxy reuse, and unblocker behavior. The output schema exists, so return values are not needed. It is complete for an agent to select and invoke correctly.

  params

  10 (1 required, 100% described)

  annotations

  readOnly=true destructive=false openWorld=true

  output schema

  yes

  cost

  1

  bytes

  6963

  hash

  eeb8fc932ea96d63

• foura_auto

  554445A4.6

  This is an excellent tool description that clearly articulates the tool's purpose, provides explicit usage guidelines with sibling differentiation, and adds rich behavioral context beyond the annotations. It effectively handles the tool's complexity by explaining key parameter semantics and operational details. The only minor improvement would be breaking the long paragraph into structured sections for even better scannability.

  5

  Purpose Clarity · 25%The description clearly states the tool's purpose: 'Give it a public URL and get the content back.' It specifies the verb (fetch), resource (public URL), and the smart escalation behavior. It also distinguishes itself from siblings by explicitly listing what it cannot do (strict exit country, pinned exit, browser choice, scripted sessions) and naming the alternative tools for those cases.

  5

  Usage Guidelines · 20%The description provides explicit when-to-use guidance: 'Use it when only the content matters and not how it is fetched.' It also gives clear when-not-to-use guidance by listing specific scenarios (strict exit country, pinned exit, browser choice, scripted sessions) and naming the appropriate sibling tools (foura_proxy, foura_single, foura_browser). This is exemplary usage guidance.

  4

  Behavioral Transparency · 20%The description adds significant behavioral context beyond the annotations. It explains the escalation strategy (direct to proxy to browser), the bounded retry behavior, the meaning of timeout_ms as a total budget, the credit reporting, and the plan_limit_ error code. While annotations already declare readOnlyHint=true and destructiveHint=false, the description enriches the safety profile with details about retries and failure modes. It doesn't contradict annotations.

  4

  Parameter Semantics · 15%The schema has 100% coverage, so the baseline is 3. The description adds value by explaining the validate.data.accept parameter's purpose ('to distinguish the real page from a challenge page') and the timeout_ms semantics ('budget for every attempt together rather than for one'). It also clarifies the returnSession parameter's role in replaying sessions. These additions go beyond the schema's basic descriptions.

  4

  Conciseness & Structure · 10%The description is a single dense paragraph that front-loads the core purpose and usage, then covers exclusions and key behaviors. It's longer than ideal but every sentence adds value—no filler. The structure flows logically from what it does, to when to use it, to what it can't do, to operational details. It could be slightly more scannable with bullet points, but it's well-organized.

  5

  Contextual Completeness · 10%Given the tool's complexity (11 parameters, nested objects, output schema, sibling tools), the description is remarkably complete. It covers the escalation behavior, validation strategy, retry semantics, timeout budget, credit reporting, error codes, and exclusions. The output schema exists, so return values don't need explanation. The description fully compensates for the tool's complexity and leaves no major gaps.

  params

  11 (1 required, 100% described)

  annotations

  readOnly=true destructive=false openWorld=true

  output schema

  yes

  cost

  1

  bytes

  10170

  hash

  9a9dba0400afa3f3

• warningfoura_proxy shadow-candidatefoura_proxy (invocation cost 5) may be shadowed by foura_auto (cost 1): if both can answer the same question, an agent tends toward the cheaper call. Only the coherence evaluation can confirm the purposes overlap; if they do, make them disjoint and say so in both descriptions, or collapse the pair.

The badge shows the overall tier and score, and links here. The JSON is the same report the CLI's hosted mode prints.

[![TDQS](https://tdqs.dev/reports/ivgtefqu60/badge.svg)](https://tdqs.dev/reports/ivgtefqu60)

The same check from a terminal, a CI job or a script, with an API key from your account. Submitting spends one of the account's daily calls; reading the result spends nothing.

export TDQS_API_KEY=tdqs_...

# exit code 1 below B, so the command is the gate; uvx runs the same command from PyPI
npx mcp-tdqs score --file tools.json --hosted https://tdqs.dev --fail-under B

curl https://tdqs.dev/api/v1/reports \
  -H 'Authorization: Bearer tdqs_...' \
  -H 'Content-Type: application/json' \
  -d @tools.json

# poll the report it names until "status" is "completed"; this one is
curl https://tdqs.dev/api/v1/reports/ivgtefqu60 \
  -H 'Authorization: Bearer tdqs_...'

import { requestHostedReport } from 'mcp-tdqs';

const report = await requestHostedReport({
  apiKey: 'tdqs_...',
  hostedUrl: 'https://tdqs.dev',
  serverName: 'foura-mcp',
  tools, // the tools/list result
});

if (report.score === null || !['A', 'B'].includes(report.score.serverScore.overallTier)) {
  throw new Error(`TDQS ${report.score?.serverScore.overallTier ?? 'failed'}: ${report.url}`);
}

from tdqs import parse_tool_definitions, request_hosted_report

parsed = parse_tool_definitions(tools_list)  # the tools/list result
report = request_hosted_report(
    api_key="tdqs_...",
    hosted_url="https://tdqs.dev",
    server_name="foura-mcp",
    tools=parsed.tools,
)
tier = report.score.server_score.overall_tier if report.score is not None else None

if tier not in ("A", "B"):
    raise SystemExit(f"TDQS {tier or 'failed'}: {report.url}")