Skip to main content
Glama

Malinois

by app.malinois
OverviewDiscussionsAdmin

Server Details

Check a live app you own for public databases, leaked keys and exposed files.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Last Tested
Transport
Streamable HTTP
URL

TDQS

A4.7/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have completely distinct purposes: scan_app performs a security scan, while explain_finding explains one specific finding. Their names and descriptions make this separation unambiguous, and there is no overlap in behavior.

Naming Consistency5/5

Both names follow a consistent verb_noun snake_case pattern: scan_app and explain_finding. This is predictable and easy to understand.

Tool Count4/5

Two tools are appropriate for what appears to be a focused security scanning service: one to run the scan and one to explain results. It is slightly lean, but no obvious operations are missing from the described scope.

Completeness4/5

The surface covers the core loop of scan and explain, which is sufficient for the stated purpose. Minor gaps, such as listing or retrieving past scan reports, could be useful but are not essential.

Available Tools

2 tools
explain_findingExplain a Malinois findingA
Read-onlyIdempotent
Inspect

Returns the plain-language meaning and step-by-step fix for one Malinois finding. Use it while helping the user fix an issue reported by scan_app, or when they ask what a finding means. Pass the rule_id exactly as scan_app returned it. Read-only, no network, instant.

ParametersJSON Schema
NameRequiredDescriptionDefault
langNoLanguage for the explanations (default: en).
rule_idYesThe rule_id of a finding, e.g. supabase_missing_rls

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint=false, idempotentHint, destructiveHint=false, yet the description adds meaningful non-annotation context: the format of the output (plain-language meaning + step-by-step fix), that it is instant (latency), and that it uses no network.

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

Conciseness5/5

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

Three short sentences that each carry a distinct piece of load-bearing information – output format, usage trigger, parameter constraint – front-loaded and free of filler.

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 small, read-only lookup tool with rich annotations and a fully documented schema, nothing an agent needs to invoke it correctly is missing; the trigger conditions, input constraint, and output shape are all covered.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds a critical semantic constraint the schema does not: rule_id must be passed exactly as returned by scan_app, i.e. it is a whitelist key, not arbitrary user input.

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 (returns plain-language meaning and step-by-step fix for one finding) and scopes it to a single entity, distinguishing it clearly from the sibling scan_app which produces findings rather than explaining them.

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?

Explicit serialization behavior ('Pass the rule_id exactly as scan_app returned it') tells the agent which value to feed in, and the trigger conditions are named explicitly: while helping fix an issue from scan_app, or when the user asks what a finding means. No ambiguity remains.

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

scan_appCheck a deployed app for data leaksA
Idempotent
Inspect

Runs a passive, outside-in security check of a live web app and returns a letter grade (A–F), each issue in plain language with fix steps, and a report link. Use when the user asks whether their deployed app is safe, before launch, or after a redeploy to confirm a fix. It checks for publicly readable Supabase/Firebase data, secret keys (Stripe, OpenAI, Supabase service_role…) in client JavaScript, downloadable .env/.git files, source maps, permissive CORS and missing security headers. Do not use it for apps the user does not own or is not authorized to test, for localhost or private addresses, or to review source code — it only sees what the public URL serves. Behavior: sends ordinary GET requests like a browser (no login, exploitation or load testing); takes about 10–30 seconds; saves the result as a report page on malinois.app, linked in the response; secrets appear only masked. Each app can be checked at most 20 times per hour.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesPublic http(s) address of the deployed app, e.g. https://my-app.lovable.app (scheme optional).
langNoLanguage for the explanations (default: en).
i_own_thisYesMust be true. Set it only after the user has explicitly confirmed they own this app or are authorized to test it; without it the check is refused.

Output Schema

ParametersJSON Schema
NameRequiredDescription
hostYes
gradeYesA (best) to F
scoreYes0–100
limitedYesTrue when the app exposed little to a passive check; a good grade is then not proof of safety.
findingsYesMost serious first.
platformNoDetected builder/host, e.g. lovable, replit
report_urlYes

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare safety flags; the description adds substantial operational context beyond them: ordinary GET requests with no login/exploitation/load testing, a 10–30 second runtime, a persisted report page on malinois.app linked in the response, secrets shown only masked, and a 20-per-hour rate limit. The readOnlyHint=false annotation is consistent with the disclosed side effect of writing a report page.

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

Conciseness5/5

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

Front-loaded with the core purpose in the first sentence, then usage, then exclusions, then behavior. Three tight paragraphs, no redundancy, and every sentence carries distinct information an agent needs.

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?

Although an output schema exists, the description still summarizes the return shape (grade, issues with fixes, report link). Combined with the consent prerequisite, authorization limits, runtime, rate limit, and scope boundaries, an agent has everything needed to decide and invoke correctly.

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%, so the schema already documents url, lang, and i_own_this, including the consent semantics and refusal behavior. The description reinforces the ownership/authorization constraint but adds no parameter-level detail (formats, defaults, enum meaning) beyond the schema, so the baseline 3 applies.

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?

The description gives a specific verb and resource ('runs a passive, outside-in security check of a live web app') plus the exact outputs (letter grade A–F, plain-language issues with fix steps, report link). It also enumerates what is checked (public Supabase/Firebase data, leaked secrets, .env/.git, source maps, CORS, headers), making it unmistakably distinct from the sibling explain_finding.

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?

Explicit triggers are given ('when the user asks whether their deployed app is safe, before launch, or after a redeploy to confirm a fix') and explicit exclusions are listed (apps the user doesn't own or isn't authorized to test, localhost/private addresses, source-code review). This is exactly the when/when-not guidance the dimension asks for.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedscan_app4 fields changed
      • changedInput schema / properties / i_own_this / description
        Previous value: -"Set to true only after the user has confirmed they own this app or are authorized to test it."New value: +"Must be true. Set it only after the user has explicitly confirmed they own this app or are authorized to test it; without it the check is refused."
      • changedInput schema / properties / url / description
        Previous value: -"Public URL of the deployed app, e.g. https://my-app.lovable.app"New value: +"Public http(s) address of the deployed app, e.g. https://my-app.lovable.app (scheme optional)."
      • addedInput schema / properties / url / maxLength
        Added value: +500
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "findings": {
+      "description": "Most serious first.",
+      "items": {
+        "properties": {
+          "evidence": {
+            "description": "Masked evidence; secrets are never returned in full.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "rule_id": {
+            "type": "string"
+          },
+          "severity": {
+            "enum": [
+              "critical",
+              "high",
+              "medium",
+              "low",
+              "info"
+            ],
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          },
+          "what_it_means": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "what_to_do": {
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "required": [
+          "rule_id",
+          "severity",
+          "title"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "grade": {
+      "description": "A (best) to F",
+      "type": "string"
+    },
+    "host": {
+      "type": "string"
+    },
+    "limited": {
+      "description": "True when the app exposed little to a passive check; a good grade is then not proof of safety.",
+      "type": "boolean"
+    },
+    "platform": {
+      "description": "Detected builder/host, e.g. lovable, replit",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "report_url": {
+      "type": "string"
+    },
+    "score": {
+      "description": "0–100",
+      "type": "number"
+    }
+  },
+  "required": [
+    "grade",
+    "score",
+    "host",
+    "limited",
+    "report_url",
+    "findings"
+  ],
+  "type": "object"
+}
  2. 2 tool updates
    • First observedexplain_finding
    • First observedscan_app

Related MCP Connectors

Related MCP Servers

  • LaunchTrust MCP

    mustafasalimerek-bit
    A
    license
    Not graded
    quality
    C
    maintenance
    Scans public URLs for compliance and security issues such as leaked API keys, exposed files, missing privacy pages, and security headers, helping developers identify gaps before launch.
    MIT

  • trust-security

    Jaden-JJH
    A
    license
    Not graded
    quality
    A
    maintenance
    Detect live website vulnerabilities and security flaws in GitHub repositories using automated DAST and SAST scanning. Safeguard applications by identifying exposed secrets, insecure dependencies, and common code patterns prone to exploitation. Receive structured fix plans with precise code remediation steps to resolve identified risks and improve security posture.
    2
    MIT

  • polaris-audit

    cnohall
    A
    license
    A
    quality
    D
    maintenance
    Audit any website for privacy, security, accessibility, and performance issues — with scores, grades, and actionable fix instructions. No account required.
    3
    10
    MIT

  • voyager-browser

    dir-ai
    A
    license
    Not graded
    quality
    B
    maintenance
    Read-only observation of a single live URL: parses static HTML to report security posture, forms, links, accessibility signals, and leaks, with described fixes. SSRF-gated and safe, never executes JavaScript.
    93
    MIT
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources