foura-mcp

• foura_single

  554445A4.6

  This is a well-crafted description that clearly defines the tool's purpose, provides explicit usage guidelines with alternatives, and adds behavioral context beyond annotations and schema. It effectively handles a complex tool with many parameters, making it easy for an agent to understand when and how to use it. Minor improvements could be made in structure, but overall it is highly effective.

  5

  Purpose Clarity · 25%The description clearly states the tool sends one HTTP request and returns the response, with specific use cases (static pages, JSON APIs, server-rendered HTML). It distinguishes from siblings by explicitly mentioning when to switch to foura_proxy (blocked response or exit country matters) and foura_browser (needs JavaScript).

  5

  Usage Guidelines · 20%Provides explicit when-to-use guidance: 'Use it for static pages, JSON APIs, and server-rendered HTML' and when to switch to alternatives: 'Switch to foura_proxy when the response is blocked or the exit country matters, and to foura_browser when the page needs JavaScript.' Also explains when to set browser/os/version and proxy usage.

  4

  Behavioral Transparency · 20%Annotations indicate readOnlyHint=true, destructiveHint=false, openWorldHint=true. The description adds valuable context: validate behavior (rejected responses come back as failure), timeout nesting, plan_limit_ codes with retryAfter, and credit reporting. It does not contradict annotations. Slight deduction for not detailing response format beyond credits, but output schema exists.

  4

  Parameter Semantics · 15%Schema coverage is 100%, so baseline is 3. The description adds meaning beyond schema: explains how validate works (rejected responses become failures), timeout nesting (timeout_ms bounds whole request, others bound stages), and proxy reuse via foura_proxy ID. It also clarifies unblocker's role in profile selection. This adds significant value over the schema.

  4

  Conciseness & Structure · 10%The description is a single dense paragraph, but it is front-loaded with the core purpose and usage. It covers many aspects efficiently without redundancy. Slight deduction for being a wall of text; could benefit from bullet points or shorter sentences, but every sentence adds value.

  5

  Contextual Completeness · 10%Given the tool's complexity (20 params, nested objects, output schema), the description covers key behavioral aspects: validation, timeouts, proxy reuse, authentication, and plan limits. It also references output schema for return values. It is complete enough for an agent to select and invoke correctly.

  params

  20 (2 required, 100% described)

  annotations

  readOnly=true destructive=false openWorld=true

  output schema

  yes

  cost

  2

  bytes

  10763

  hash

  74d54e4454c93a67

• foura_proxy

  Shadowing Risk554445A4.6

  This is an exemplary tool description that clearly explains the tool's purpose, usage, and behavioral nuances, distinguishing it from siblings and providing actionable guidance. It adds significant value beyond the schema and annotations, covering retry logic, exit selection, and error handling. The only minor improvement could be breaking the long paragraph into structured sections, but it is already highly effective.

  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 noting it is the only tool with strict exit-country allowlist, named browser family, and premium exit escalation. It also mentions when to use it (when foura_single is blocked) and when to use foura_browser (when JavaScript is needed).

  5

  Usage Guidelines · 20%The description provides explicit guidance on when to use this tool versus alternatives: 'Use it when foura_single is blocked' and 'Use foura_browser when the page needs JavaScript.' It also explains key parameters like maxTries, timeout_ms, and exitCountries, and notes that rotation costs several times a single request, helping the agent decide if this tool is appropriate.

  4

  Behavioral Transparency · 20%The description goes beyond annotations by explaining the retry behavior, the meaning of exitClass as an allowance rather than instruction, the interaction between timeout_ms and maxTries, and the response structure (returning exit id or attemptReport). It also discloses that a plan refusal arrives as plan_limit_ code with retryAfter. However, it does not explicitly mention the readOnlyHint or openWorldHint, but these are already in annotations, so no contradiction. The description adds significant behavioral context, but could be slightly more explicit about the read-only nature (though it's implied by 'route an HTTP request' and the annotations).

  4

  Parameter Semantics · 15%The schema has 100% coverage, so the baseline is 3. The description adds value by explaining the semantics of key parameters: exitCountries never falls back, exitClass is an allowance, maxTries bounds attempts, timeout_ms bounds the whole rotation, and validate determines what counts as delivered. It also explains the interaction between timeout_ms and maxTries, which is not in the schema. This goes beyond the schema descriptions, so a 4 is appropriate.

  4

  Conciseness & Structure · 10%The description is a single dense paragraph that covers many aspects, but it is well-structured and front-loaded with the core purpose. It is longer than ideal but every sentence adds value, covering usage, key parameters, response handling, and cost. It could be broken into shorter sentences for readability, but it is not verbose or redundant.

  5

  Contextual Completeness · 10%Given the tool's complexity (7 parameters, nested objects, output schema, and multiple sibling tools), the description is remarkably complete. It explains the retry logic, validation, exit selection, response format, error handling, and cost implications. The output schema exists, so return values are covered, but the description still explains the attemptReport and exit id usage. It also covers edge cases like plan_limit_ codes and ssrf_blocked. This is a comprehensive description for a complex tool.

  params

  7 (1 required, 100% described)

  annotations

  readOnly=true destructive=false openWorld=true

  output schema

  yes

  cost

  5

  bytes

  14448

  hash

  62275d92503e8c76

• foura_browser

  554445A4.6

  This is an excellent tool description that clearly defines the purpose, provides explicit usage guidelines with alternatives, and adds significant behavioral context beyond the annotations and schema. It is slightly dense but well-structured and complete for a complex tool. The only minor improvement would be formatting, but the content is top-tier.

  5

  Purpose Clarity · 25%The description clearly states the tool loads a public URL in a full browser session, with JavaScript and DOM rendering, and distinguishes it from siblings by noting it is the most expensive and slowest, and that foura_single or foura_proxy should be preferred when content is in HTML. This is a specific verb+resource with clear scope and differentiation.

  5

  Usage Guidelines · 20%The description explicitly states when to use this tool (single-page apps, lazy-loaded content, supported browser challenges) and when not to (prefer foura_single or foura_proxy when content is already in HTML). It also provides a clear workflow: call foura_proxy first for protected pages and pass its proxy ID. This is explicit when/when-not guidance with alternatives named.

  4

  Behavioral Transparency · 20%Annotations declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context: it mentions that cookies come back with the response, that checkStatus/checkText turn wrong-page navigations into failures, that unblocker:false returns the page as-is including challenges, and that a plan refusal returns plan_limit_ codes. It also notes the cost and slowness. This goes beyond annotations, though it doesn't detail the output schema structure, but that is covered by the output schema.

  4

  Parameter Semantics · 15%Schema description coverage is 100%, so the schema already documents all parameters. The description adds value by explaining the proxy reuse mechanism (base36 ID from foura_proxy) and the checkStatus/checkText behavior, which are not fully captured in the schema. It also clarifies the unblocker default and the offload_large behavior. This is above the baseline 3 because it provides meaningful context beyond the schema.

  4

  Conciseness & Structure · 10%The description is a single dense paragraph, but it is front-loaded with the core purpose and then covers usage, alternatives, and error handling. It is not overly verbose, but it could be improved with bullet points or shorter sentences for readability. Every sentence adds value, so it earns a 4.

  5

  Contextual Completeness · 10%Given the tool's complexity (10 parameters, nested objects, output schema, and sibling tools), the description is remarkably complete. It covers when to use, how to use with proxy, error handling (checkStatus/checkText, plan_limit codes), cost implications, and alternatives. The output schema exists, so return values are not needed in the description. This is a comprehensive description for a complex tool.

  params

  10 (1 required, 100% described)

  annotations

  readOnly=true destructive=false openWorld=true

  output schema

  yes

  cost

  1

  bytes

  6873

  hash

  05c29825e0522ec8

• foura_auto

  555445A4.8

  This is an exemplary tool description that fully leverages the available space to provide clear purpose, usage guidelines, behavioral transparency, and parameter semantics. It explicitly differentiates from siblings and covers edge cases like validation and timeouts. The only minor critique is its length, but the density of useful information justifies it.

  5

  Purpose Clarity · 25%The description clearly states the tool's purpose: 'Give it a public URL and get the content back' with a specific verb and resource. It distinguishes itself from siblings by explicitly listing what it cannot do and pointing to foura_proxy, foura_single, and foura_browser for those capabilities.

  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 exclusions: 'What it cannot do is the reason to reach for another tool' and details which sibling handles each alternative scenario, such as strict exit country, pinned exit, browser choice, and scripted sessions.

  5

  Behavioral Transparency · 20%The description goes beyond the readOnlyHint and openWorldHint annotations by explaining the escalation behavior (direct to proxy to browser), the bounded attempts, the inability to guarantee a match, the ownership of retry settings (no maxTries), the timeout_ms as a total budget, and the authentication and credit reporting. It also clarifies that a plan_limit_ code is a refusal by the plan, not a target block.

  4

  Parameter Semantics · 15%The schema has 100% coverage, so the baseline is 3. The description adds value by explaining the semantics of key parameters: validate.data.accept for protected targets, timeout_ms as a total budget for all attempts, ignoreProxies for rotating away from blocked exits, and returnSession for replaying the session. It also clarifies that exitClass is shared with foura_proxy and that forceProxy defaults to true.

  4

  Conciseness & Structure · 10%The description is dense but well-structured, with a clear flow from purpose to usage to exclusions to operational details. It is longer than ideal, but every sentence adds meaningful information about behavior, parameters, or alternatives. The front-loading is effective: the first sentence states the core purpose, and the rest elaborates on important nuances.

  5

  Contextual Completeness · 10%Given the tool's complexity (12 parameters, nested objects, output schema, and multiple siblings), the description is remarkably complete. It covers the escalation logic, validation usage, retry behavior, timeout semantics, authentication, credit reporting, and clear differentiation from siblings. The output schema exists, so return values are not the description's burden, but it still mentions the result reports credits and offloaded_resource_uri.

  params

  12 (1 required, 100% described)

  annotations

  readOnly=true destructive=false openWorld=true

  output schema

  yes

  cost

  1

  bytes

  10705

  hash

  f791e95978131292

• 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/ogacknph95/badge.svg)](https://tdqs.dev/reports/ogacknph95)

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/ogacknph95 \
  -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}")