Synthex Forge — x402 Paid Agent Services

Assess Business Eligibility

assess_business_eligibility

Destructive

A structured screen of an SME on turnover, EBITDA. use it rather than verify_business_screen for business eligibility, not business screen; an object with 7 fields including detail, error. $2.5 USDC.

Input Schema

Name	Required	Description
`notes`	No	Free text. Used only for the Rule B food-service check. It is NOT stored, NOT logged and NOT returned.
`sector`	No	The sector, free text, e.g. 'Business services — accounting & tax advisory'. Used for Rule B (food service) and for the benchmark bucket. Matching is word-boundary and accent-insensitive.
`location`	No	The location, free text, e.g. 'Lisboa'. Echoed back in the response; it is the caller's own input, not pipeline data.
`employees`	No	Headcount. Optional; reported in the echoed input block.
`price_eur`	No	The asking price in EUR. REQUIRED.
`structure`	No	The capital structure. 'house' is the ONLY supported structure in v1. Anything else is NAMED in coverage_gaps — it is never silently modelled as something it is not.
`ebitda_eur`	No	Annual EBITDA in EUR. REQUIRED. Undisclosed is NOT zero — an undisclosed figure returns insufficient_data, never a model.
`turnover_eur`	No	Annual turnover (revenue) in EUR. REQUIRED.
`exit_multiple`	No	The exit EV/EBITDA multiple. Optional; the house base case of 4.0x is applied and the default is named in coverage_gaps.
`seller_financing_pct`	No	Seller financing offered, as a percentage of price. The house approach is 20-30%, so 20 or more is reported as 'preferred' and less as 'absent'.

Output Schema

Name	Required	Description
`note`	No	A note on how the answer was produced.
`error`	No	The machine-readable error code, when the operation failed.
`detail`	Yes	Human-readable explanation of the verdict.
`x402Version`	No	The `x402Version` field of the response.
`missing_fields`	No	The `missing_fields` field of the response.
`optional_fields`	No	The `optional_fields` field of the response.
`required_fields`	No	The `required_fields` field of the response.

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedOct 31, 2026

addedOutput schema / properties / detail

Added value: +{
+  "description": "Human-readable explanation of the verdict.",
+  "type": "string"
+}

addedOutput schema / properties / error

Added value: +{
+  "description": "The machine-readable error code, when the operation failed.",
+  "type": "string"
+}

addedOutput schema / properties / missing_fields

Added value: +{
+  "description": "The `missing_fields` field of the response.",
+  "type": "object"
+}

addedOutput schema / properties / note

Added value: +{
+  "description": "A note on how the answer was produced.",
+  "type": "string"
+}

addedOutput schema / properties / optional_fields

Added value: +{
+  "description": "The `optional_fields` field of the response.",
+  "type": "object"
+}

addedOutput schema / properties / required_fields

Added value: +{
+  "description": "The `required_fields` field of the response.",
+  "type": "object"
+}

removedOutput schema / properties / status

Removed value: -{
-  "type": "string"
-}

addedOutput schema / properties / x402Version

Added value: +{
+  "description": "The `x402Version` field of the response.",
+  "type": "object"
+}

addedOutput schema / required
```
Added value: +[
+  "detail"
+]
```

AddedOct 31, 2026

TDQS

B3.3/5.0

Behavior3/5

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

It discloses two things annotations do not: the response shape (an object with 7 fields including detail and error) and a hard cost of $2.5 USDC per call, which matters a lot for call planning. Against that, it never mentions permissions, limits, or that the tool consumes paid balance, and there is a visible tension between a "screen"/return-object framing and the destructiveHint=true, readOnlyHint=false annotations that suggests a charge or side effect the description does not explain.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is short and front-loads the purpose, but the text reads as clipped fragments with a dangling quote and an awkward double clause ("business eligibility, not business screen"), so the density costs clarity rather than buying it.

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

Completeness4/5

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

For a 10-parameter assessment tool with a full schema, complete annotations, and an output schema, the description supplies the pieces structured fields cannot: the sibling to avoid and the per-call price. Output values need not be explained because an output schema exists. What is missing is what eligibility is judged against, so it falls short of complete.

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

Parameters3/5

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

Schema description coverage is 100% and every field is documented in the input schema, so the schema already carries full semantic weight and the baseline is 3. The description mentions only turnover and EBITDA and adds no field-level meaning (structure, seller_financing_pct, exit_multiple rules) beyond what the schema states.

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

Purpose3/5

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

It names the resource (an SME) and a loose verb ("structured screen") over turnover/EBITDA, which is enough to know it is an eligibility assessment rather than, say, a document tool. But the sentence is a fragment ("...on turnover, EBITDA.") and never states the actual verdict/outcome it produces, so the agent learns the inputs screened but not what decision the tool renders.

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

Usage Guidelines4/5

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

It routes explicitly against a named sibling: use this rather than `verify_business_screen` when the goal is business eligibility rather than business screening. That is a concrete alternative-plus-condition. It loses a point only because the caveat "for business eligibility, not business screen" is circular and does not tell the agent what `verify_business_screen` actually returns differently.

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

All Synthex Forge — x402 Paid Agent Services tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.