7IT Solutions

Deep security scan of an app you control

deep_scan_app

Read-onlyIdempotent

Use this when the user, or the agent building the app, wants to check an app they control for exposed files and leaked secret keys before launch. A deeper security scan than check_app_security, for an app the caller controls (for example one the agent itself is building). It looks for sensitive things left publicly reachable: an environment (.env) file, an exposed .git folder, a directory listing, or a published source map. It also reads the app's own public code (the home page and its scripts) for the Supabase project it uses and for secret keys shipped to the browser (a Supabase service role or secret key, a database password, a paid AI key). It never contacts the app's database, never writes, and never stores, logs or returns any key; it reports the exposed PATH or the KIND of key, never a file's contents or a secret value. Because it probes an app directly, each scan runs only after ownership is proven now: call it once to receive a one-time code and a check id, add the code to the app (a meta tag on the home page, or a line in /7it-verify.txt), then call again with the check id and the scan runs.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes	The app’s public web address, for example myapp.com or https://myapp.lovable.app. You must be able to add a verification code to this app.
`check`	No	The check id the first call returned, after the one-time code is on the app

Output Schema

TableJSON Schema

Name	Required	Description
`code`	No	One-time verification code to place on the app (30 minutes)
`host`	No
`check`	No	The check id to pass on the next call, once the code is on the app
`clean`	No	True when no exposed file was found
`token`	No	The site's ownership token (for the 7IT Guard watch; it no longer unlocks a scan by itself)
`backend`	No	The Supabase project the public code names, and how many secret keys it carries (the database is never contacted)
`findings`	No	Exposed paths, plus secret keys in the public code by kind; file contents and key values are never returned
`verified`	No
`report_url`	No
`needs_verification`	No	True when ownership is not proven yet; add the code and call again with the check id

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 7, 2026

addedInput schema / properties / check

Added value: +{
+  "description": "The check id the first call returned, after the one-time code is on the app",
+  "maxLength": 500,
+  "type": "string"
+}

changedInput schema / properties / url / description

Previous value: -"The app’s public web address, for example myapp.com or https://myapp.lovable.app. You must be able to add a verification token to this app."New value: +"The app’s public web address, for example myapp.com or https://myapp.lovable.app. You must be able to add a verification code to this app."

addedOutput schema / properties / check

Added value: +{
+  "description": "The check id to pass on the next call, once the code is on the app",
+  "type": "string"
+}

addedOutput schema / properties / code

Added value: +{
+  "description": "One-time verification code to place on the app (30 minutes)",
+  "type": "string"
+}

changedOutput schema / properties / needs_verification / description

Previous value: -"True when ownership is not proven yet; add the token and call again"New value: +"True when ownership is not proven yet; add the code and call again with the check id"

changedOutput schema / properties / token / description

Previous value: -"Inert verification token to place on the app"New value: +"The site's ownership token (for the 7IT Guard watch; it no longer unlocks a scan by itself)"

Changed2 schema fields changedOct 5, 2026

changedOutput schema / properties / backend / description

Previous value: -"What was found behind the app: supabase/firebase presence and how many tables an anonymous visitor could read"New value: +"The Supabase project the public code names, and how many secret keys it carries (the database is never contacted)"

changedOutput schema / properties / findings / description

Previous value: -"Exposed paths, plus open backend tables/buckets with a row count; file contents and key values are never read or returned"New value: +"Exposed paths, plus secret keys in the public code by kind; file contents and key values are never returned"

Changed5 schema fields changedOct 3, 2026

addedOutput schema / properties / backend

Added value: +{
+  "additionalProperties": {},
+  "description": "What was found behind the app: supabase/firebase presence and how many tables an anonymous visitor could read",
+  "properties": {},
+  "type": "object"
+}

changedOutput schema / properties / findings / description

Previous value: -"Exposed paths only; file contents are never read or returned"New value: +"Exposed paths, plus open backend tables/buckets with a row count; file contents and key values are never read or returned"

addedOutput schema / properties / findings / items / properties / detail
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / findings / items / properties / kind
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / findings / items / properties / rows
```
Added value: +{
+  "type": "number"
+}
```

Changed1 schema field changedOct 1, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "properties": {
+    "clean": {
+      "description": "True when no exposed file was found",
+      "type": "boolean"
+    },
+    "findings": {
+      "description": "Exposed paths only; file contents are never read or returned",
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "fix": {
+            "type": "string"
+          },
+          "id": {
+            "type": "string"
+          },
+          "label": {
+            "type": "string"
+          },
+          "path": {
+            "type": "string"
+          },
+          "severity": {
+            "enum": [
+              "critical",
+              "high",
+              "medium"
+            ],
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "label",
+          "path",
+          "url",
+          "severity",
+          "fix"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "host": {
+      "type": "string"
+    },
+    "needs_verification": {
+      "description": "True when ownership is not proven yet; add the token and call again",
+      "type": "boolean"
+    },
+    "report_url": {
+      "type": "string"
+    },
+    "token": {
+      "description": "Inert verification token to place on the app",
+      "type": "string"
+    },
+    "verified": {
+      "type": "boolean"
+    }
+  },
+  "type": "object"
+}

AddedOct 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description still adds substantial behavior: never contacts the app's database, never writes, never stores/logs/returns key values, and only reports the PATH or KIND of a finding. It also discloses the unusual two-call ownership-verification handshake, which no annotation conveys.

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

Conciseness4/5

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

It is long but dense and front-loaded: the trigger comes first, then scope, then safety guarantees, then the call sequence. Nearly every sentence carries new information, though the single paragraph could be broken up for faster scanning.

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

Completeness5/5

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

For a 2-param probe tool with an output schema, it covers everything an agent needs: when to call, the sibling alternative, the two-step ownership flow, safety guarantees, and what kinds of findings are returned. Nothing critical is left to inference.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description goes further by explaining the lifecycle of 'check' — the first call returns a one-time code and check id, the code is placed on the app, and the second call uses that id to actually run the scan. That adds meaning beyond the schema's terse field note.

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

Purpose5/5

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

States a specific verb+resource (deep security scan of an app) and enumerates exactly what it looks for: exposed .env, .git, directory listing, source maps, and secret keys shipped to the browser. It explicitly positions itself against the sibling check_app_security as 'a deeper security scan'.

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

Usage Guidelines5/5

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

Names the trigger condition ('when the user, or the agent building the app, wants to check an app they control... before launch'), names the alternative tool and how this differs, and gives the full when-to-use precondition (ownership must be provable on the target app).

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

All 7IT Solutions tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?