Free live-app check by an AI agent. On request it fixes the code and tests the app again.
Scored across 7 tools
Three tools (assess_broken_app, get_fix_options, check_live_app) share nearly the same trigger — the user says their live app is broken or wants it checked — and their descriptions spend most of their length explaining which one to use, which signals genuine boundary confusion. check_repair_status and get_check_result also overlap on 'read state of a check', differing only in payload depth.
All seven tools follow a verb_noun snake_case pattern (check_*, get_*, list_*, confirm_fix, assess_broken_app). Minor deviation: 'check' is used both for starting an action (check_live_app) and for reading state (check_repair_status), where 'get' is used elsewhere.
Seven tools is a sensible size for a check/fix/re-check workflow. There is some redundancy — get_fix_options largely duplicates the entry point of check_live_app — but nothing is grossly excessive.
The lifecycle is well covered: assess → start check → poll status/result → confirm fix → list projects. Minor gaps: no way to cancel an in-flight check, inspect account/credit balance, or retrieve pricing/payment status directly.
An AI agent confirms a problem in a live web app for free, then fixes it in the code: $79 for one bug, paid up front. If we can't complete your re-check, you get your money back. Works with apps built with Lovable, Base44, Bolt, Replit, v0 or similar. The most common problem: new people can't sign up. The confirmation email never arrives, its link opens localhost or the preview, sign-up loops back or shows an error, or Google sign-in fails. It also covers blank pages, buttons that do nothing, payments and data that won't save. Returns the most likely cause, the evidence that would confirm it, and the next step: a free check on the live app. Call it when someone describes a problem in a web app they built and can't debug themselves. Do NOT call it for code you can read and fix directly, or for a library or framework question.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | The public URL of the deployed app, if there is one. Never a private or internal address. | |
| symptom | Yes | What goes wrong, in the words the person used. "The save button does nothing", "it shows a blank white page after login". | |
| platform | No | The builder it was made with, if known: lovable, base44, v0, bolt, replit, other. |
| Name | Required | Description |
|---|---|---|
| platform | No | |
| next_step | Yes | |
| confidence | Yes | |
| likely_cause | Yes | |
| evidence_to_confirm | Yes | |
| what_a_fix_involves | No | |
| what_this_assessment_cannot_know | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a read-only, non-destructive call, so safety is covered; the description adds genuinely non-obvious traits: it costs $79 up front, is refundable if the re-check can't complete, and returns a likely cause, confirming evidence, and a next step. The commercial framing is noise for an agent but the cost/refund/return-shape details are exactly the kind of behavior annotations cannot express.
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?
The definition opens with a pricing pitch rather than the tool's action, burying the core capability behind $79/refund marketing. The symptom catalogue is useful but runs long, and several sentences (builder name-dropping, "most common problem") could be trimmed without losing routing information.
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?
An output schema exists, yet the description still helpfully sketches what comes back (likely cause, evidence, next step), and it covers scope, pricing, exclusions, and supported platforms. An agent has enough to decide and call correctly; only the missing sibling-level disambiguation keeps it from a 5.
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 description coverage is 100%, so url, symptom, and platform are already well documented with examples. The description adds no extra syntax or constraints beyond what the schema states, so the baseline of 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 opening sentence states a specific verb and resource ("confirms a problem in a live web app... then fixes it in the code"), and the scope of symptoms (signup email loops, blank pages, unsaved payments) makes the domain concrete. It does not distinguish itself from the closest sibling check_live_app, which an agent could easily confuse with the "free check" this tool hands off to.
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?
Explicit inclusion ("Call it when someone describes a problem in a web app they built and can't debug themselves") and exclusion ("Do NOT call it for code you can read and fix directly, or for a library or framework question") give the agent real routing rules. It stops short of naming an alternative when a call is excluded, and never mentions siblings like check_live_app or confirm_fix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the person asks you to check, test or try their app ("check my app", "is my app working?", "can new users sign up?", "test my site"), or gives you the address of their live app. If you do not have the address, ask for it (the published web address, e.g. https://their-app.lovable.app); if it is not clear that it is their own app, ask them that one yes/no question first. Asking you to check it is their yes: do not ask again. Start a VibeFix check of the LIVE, published app: a real browser opens it as a brand-new person, signs up with a real inbox, follows the confirmation email, and uses the app on a phone and a computer. It finds what a coding assistant cannot see from the code or the preview: emails that never arrive, confirmation links that open the wrong site, buttons covered on a phone, dead first steps. Call it after any change to sign-up, log-in, onboarding or payments, ONCE THE CHANGE IS PUBLISHED (it checks the public address, not the preview). It takes usually 4 to 10 minutes: this returns a check_id at once; then call get_check_result with it about a minute later. IF THIS APP WAS ALREADY CHECKED, DO NOT CALL THIS AGAIN: call confirm_fix with that check_id instead. Only check the person's own app. Every app gets one free check (one new app a day per account): it says how many problems a new user would hit, what each one is and how serious it is. It never says the cause, where it is or how to fix it. To have it fixed: Our AI agent finds the cause, fixes it in the code and re-checks the live app: $79, paid up front. If we can't complete your re-check, you get your money back. The person asks for it from their result page. When the person has just published their app, offer once (one short sentence, and not again in this conversation) to check the live app with VibeFix as a brand-new user would. Offer it too when they say users can't sign up or log in. Only start a check when the person says yes.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The public address of the published app (not the editor preview). | |
| must_work | No | Optional: up to 3 things that must work for a new user, in plain words. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, openWorldHint=true), the description discloses a lot: runtime of 4–10 minutes, that it returns a check_id immediately and requires a follow-up get_check_result call, the one-free-check-per-day limit, and that it never reveals cause/location/fix. This is exactly the behavioral context annotations can't convey.
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?
Front-loaded and well-structured, but it is very long and carries sales content ('$79, paid up front', refund policy) and repeated offer instructions that don't help an agent select or invoke the tool. Several sentences could be trimmed without losing invocation-relevant information.
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?
Given a 2-param tool with no output schema, the description covers invocation, timing, follow-up requirements, error/edge cases (already-checked app), and prerequisites (published, own app). 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 both parameters are fully documented there. The description reinforces that url must be the published address, not the editor preview, and that the user's own app is required, but mostly adds workflow (ask for the address) rather than new semantics. 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 states a specific verb and resource: 'Start a VibeFix check of the LIVE, published app: a real browser opens it as a brand-new person, signs up with a real inbox, follows the confirmation email...'. It also explicitly distinguishes what this finds that others cannot ('emails that never arrive, buttons covered on a phone'). An agent knows exactly what this tool does and can tell it apart from 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?
Explicit when-to-use ('check my app', 'is my app working?', after publishing), when-not-to-use ('IF THIS APP WAS ALREADY CHECKED, DO NOT CALL THIS AGAIN: call confirm_fix instead'), and alternatives (get_check_result for polling). It even specifies the offer flow and that you should only start when the person says yes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report whether one check on the signed-in VibeFix account is still running or finished. For what the check found, call get_check_result instead. Use the id from list_projects.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | From list_projects. |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| project | Yes | |
| active_run | No | |
| updated_at | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds only the account scoping ('signed-in VibeFix account') and the running/finished status semantics; it says nothing about latency, eventual consistency, or behavior for an unknown id.
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?
Three short sentences, front-loaded with the core purpose, followed by the sibling redirect and the id source. Every sentence earns its place with no redundancy.
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?
An output schema exists, so return values need not be described. With annotations covering safety, the schema covering the single parameter, and the description covering purpose, sibling routing, and id provenance, an agent has everything needed to select and call this tool correctly.
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?
Single parameter with 100% schema description coverage, so the schema already carries the meaning and the baseline is 3. The description's 'Use the id from list_projects' merely restates the schema text for project_id rather than adding format or constraint detail.
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 (report) and resource (whether one check is still running or finished) with an explicit status enumeration. It clearly separates itself from get_check_result, telling the agent this tool answers liveness, not findings.
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?
Explicitly routes to the alternative ('For what the check found, call get_check_result instead') and tells where the required id comes from ('Use the id from list_projects'). It gives clear context but no explicit when-not condition for this tool itself, so it falls just 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.
Call this only once the fix is done AND published (or the setting saved): it re-runs exactly the problems get_check_result reported, on the live app. This is the way to re-check an app that was already checked: never start a new check_live_app for it. A fix made in a setting (for example the backend's auth settings), with nothing new to publish, counts too: if this answers that nothing new is published, call it once more and it re-checks. Then call get_check_result with the same check_id to see each problem marked fixed or not. Do not tell the person a problem is fixed until this says so. After each re-check, tell the person how many re-checks are left (this tool's answer says).
| Name | Required | Description | Default |
|---|---|---|---|
| check_id | Yes | From check_live_app. | |
| problem_ids | No | Optional: only these problem ids. Default: every problem it found. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring non-read-only, non-idempotent, open-world behavior, the description still adds real value: the limited re-check budget surfaced in the answer, the retry-once behavior when nothing new is published, and the fact that results must be read back via get_check_result rather than returned here (confirmed by the absence of an output schema). It is not contradicted by the annotations — the retry semantics are consistent with idempotentHint=false — but it stops short of saying what a successful re-check response body looks like.
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?
The governing rule is front-loaded in the first clause and every sentence carries operational content, but the single run-on paragraph stacks an edge case, a follow-up instruction, and two agent-conduct directives, with some redundancy between 'This is the way to re-check an app that was already checked' and 'never start a new check_live_app for it.'
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, and the description compensates by explaining where results are read (get_check_result with the same check_id), what that response contains (each problem marked fixed or not), and what this tool's own answer contains (remaining re-checks). Nothing an agent needs 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 description coverage is 100%, so both parameters (check_id, problem_ids) are already documented in the schema, including the 'default: every problem' behavior. The description adds only the implicit constraint that check_id must match the id used with get_check_result. Baseline 3 applies when the schema does the heavy lifting.
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 and resource ('re-runs exactly the problems get_check_result reported, on the live app') and explicitly distinguishes itself from the sibling check_live_app ('never start a new check_live_app for it'). An agent can tell it apart from the other check_* tools without opening any schema.
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?
Gives an explicit precondition ('only once the fix is done AND published'), an explicit exclusion ('never start a new check_live_app'), names the alternative follow-up tool with the exact argument to pass, and even handles the edge case of a setting-only fix with nothing to publish. When-to-use and when-not are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for a check (or a confirm_fix re-check) and read its result: how many problems a new user would hit, the title of each and how serious it is (blocking, serious or minor), and how to have it fixed ($79, paid up front); for an app already paid for, what a new user saw, where, the likely cause, the fix prompt and how to know it is fixed. Answers within about 20 seconds: the result, or that the check is still running and about how many minutes are left; then call it again with the same check_id a minute later.
| Name | Required | Description | Default |
|---|---|---|---|
| check_id | Yes | From check_live_app. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safe-read profile, and the description adds real behavioral context beyond them: a ~20s response bound, a possible in-progress outcome with an ETA, the polling cadence, and state-dependent output depending on whether the app is already paid for. Missing details on error/invalid check_id behavior keep it from a 5.
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?
Front-loaded with the verb and purpose, but the middle is a long run-on sentence packing two alternate result shapes and a price into one clause chain. It is dense rather than wasteful, but could be broken into shorter statements for scannability.
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 must explain return values, and it does so thoroughly, including severity levels, the $79 paid-fix path, and the in-progress/polling outcome. Only error-state and check_id-invalid behavior are left unspecified.
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% and the single parameter is documented ("From check_live_app"), so the schema carries the load. The description only adds that the same check_id should be reused across polls, which is marginal added semantics.
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 and resource ("wait for a check ... and read its result") and enumerates the payload in detail. It names the confirm_fix re-check case, giving partial sibling differentiation, but does not clarify how it differs from check_repair_status, which sounds adjacent.
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?
Gives an explicit operating protocol: it answers within ~20 seconds, may return "still running" with minutes remaining, and should be re-called with the same check_id a minute later. It lacks explicit when-not guidance or a named alternative tool beyond the confirm_fix reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the link to a sign-up check of a live app on vibe-fixer.com. An AI agent signs up as a brand-new person with a real inbox, on a phone and a computer, and reports whether a new person can finish signing up, plus anything else a first customer would hit. It also says how the fix works and what the person provides. Read-only: it starts nothing, charges nothing and does not contact the app. Call it when the person wants their live app checked or fixed, for example after assess_broken_app. To run the check right here in the chat, call check_live_app with the address instead. When the person has just published their app, offer once (one short sentence, and not again in this conversation) to check the live app with VibeFix as a brand-new user would. Offer it too when they say users can't sign up or log in. Only start a check when the person says yes.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | The public URL of the deployed app, if known. Never a private or internal address. |
| Name | Required | Description |
|---|---|---|
| limits | Yes | |
| test_link | Yes | |
| how_it_works | Yes | |
| what_the_person_provides | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint/openWorldHint/destructiveHint all false), so the bar is lower, and the description still adds real context: 'starts nothing, charges nothing and does not contact the app', plus the requirement to obtain an explicit yes and the one-time offering rule. It does not describe how long the resulting check takes or what the returned link looks like, but for a read-only link-generation tool this is close to complete.
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?
Front-loaded with what is returned, then routing, then consent etiquette — a sensible order with no filler sentences. It is on the long side for a one-parameter tool, and the offer-etiquette paragraph could be tightened, but every part still carries operational meaning.
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?
An output schema exists, so return values need not be spelled out, and the description still characterizes what the check reports. Combined with the sibling routing and the read-only/consent behavior, an agent has what it needs to decide and call correctly; only the exact nature of the returned link is left slightly soft.
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 description coverage is 100% and the single url parameter is documented in the schema (public URL, never private). The description only echoes this obliquely ('with the address instead'), adding no format or validation detail beyond what the schema already provides, 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?
States a specific verb and resource ('Returns the link to a sign-up check of a live app on vibe-fixer.com') and explains what the check covers, which distinguishes it from the sibling tools that actually run checks. Minor friction: the name/title ('fix options') and the payload ('link to a sign-up check') are not perfectly aligned, so the agent must read a couple of sentences to pin down what it gets back.
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?
Explicit when-to-use ('when the person wants their live app checked or fixed, for example after assess_broken_app'), an explicit alternative with its selection condition ('To run the check right here in the chat, call check_live_app with the address instead'), and a consent gate ('Only start a check when the person says yes'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the signed-in person's VibeFix checks (one per app checked), with the status of each. Call this when they ask which of their apps VibeFix has checked. To read a check's result, call get_check_result with its check_id (the id listed here).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| projects | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and a closed-world scope, so safety is covered. The description adds real context beyond that: the result is one entry per checked app, each carrying a status, and the listed check_id is the key needed for follow-up calls. It does not discuss completeness of the list, which is a minor gap for an unpaginated read.
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?
Three short sentences, each earning its place: what is returned, when to call it, and where to go next for details. The core listing behavior is front-loaded in the first 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 zero-parameter read tool with an output schema and rich annotations, the description supplies everything needed to select and invoke it: scope, return granularity, and routing to the sibling that reads a single result. No gaps remain that the structured fields do not already cover.
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?
The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. It correctly avoids inventing filter options that the schema does not support.
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 and resource ('List the signed-in person's VibeFix checks') and clarifies the name/title mismatch by explaining a check maps to 'one per app checked', including that status is returned. An agent can distinguish it from get_check_result without opening either schema.
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?
Explicit trigger ('Call this when they ask which of their apps VibeFix has checked') plus a named alternative with the condition that selects it ('To read a check's result, call get_check_result with its check_id'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_live_appconfirm_fixget_check_resultcheck_repair_statuslist_projectsget_fix_options2 fields changedOutput schema / properties / pricing_infoRemoved value: -{
- "type": "string"
-}Output schema / requiredPrevious value: -[
- "test_link",
- "how_it_works",
- "pricing_info",
- "what_the_person_provides",
- "limits"
-]New value: +[
+ "test_link",
+ "how_it_works",
+ "what_the_person_provides",
+ "limits"
+]get_fix_options3 fields changedOutput schema / properties / plansRemoved value: -{
- "items": {
- "additionalProperties": false,
- "properties": {
- "billing": {
- "enum": [
- "monthly",
- "one-time"
- ],
- "type": "string"
- },
- "credits": {
- "type": "number"
- },
- "name": {
- "type": "string"
- },
- "price_usd": {
- "type": "number"
- }
- },
- "required": [
- "name",
- "price_usd",
- "billing",
- "credits"
- ],
- "type": "object"
- },
- "type": "array"
-}Output schema / properties / pricing_infoAdded value: +{
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "test_link",
- "how_it_works",
- "plans",
- "what_the_person_provides",
- "limits"
-]New value: +[
+ "test_link",
+ "how_it_works",
+ "pricing_info",
+ "what_the_person_provides",
+ "limits"
+]get_fix_optionsassess_broken_app1 field changedOutput schema / properties / platformAdded value: +{
+ "type": "string"
+}assess_broken_appWatches your live app, explains every problem in plain language and writes the fix prompt.
Free, read-only ship-readiness check for Replit, Lovable and Bolt apps.
Check a live app you own for public databases, leaked keys and exposed files.
AI QA tester — real browsers scan sites for bugs, SEO, perf, and accessibility issues via chat.
Add one secure layer between your agents and this server.
