Outrings Web Intelligence

Generate an embeddable verification badge

get_badge_embed

Read-onlyIdempotent

Produce the HTML (and Markdown) for a badge the site owner can paste into their footer or README. It renders a live SVG showing a real measured score that refreshes every six hours and links through to the full audit, so a visitor can verify it. Use this when someone wants to display that their site was checked.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "get_badge_embed"
  }
}

Input Schema

Name	Required	Description	Default
`url`	Yes	The website to inspect. A bare domain works: "example.com" is treated as https://example.com.
`style`	No	Badge shape. score shows the number, verified shows a tick and wordmark, shield is the flat two-part style used by build badges, compact is the smallest.	score
`theme`	No	Colour scheme to match the page it will sit on.	light
`metric`	No	Which score the badge displays. Use overall unless the site wants to highlight one category.	overall

Output Schema

Name	Required	Description
`host`	Yes
`html`	Yes	Ready-to-paste anchor and image markup.
`linkUrl`	No	Full report the badge links to, so a visitor can verify the score.
`imageUrl`	Yes	Live SVG badge; re-renders from a real audit every six hours.
`markdown`	No	The same badge for a README.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

changedInput schema / properties / url / description

Previous value: -"The website to inspect. A bare domain works — \"example.com\" is treated as https://example.com."New value: +"The website to inspect. A bare domain works: \"example.com\" is treated as https://example.com."

Changed4 schema fields changedAug 20, 2026

addedInput schema / properties / metric / description

Added value: +"Which score the badge displays. Use overall unless the site wants to highlight one category."

addedInput schema / properties / style / description

Added value: +"Badge shape. score shows the number, verified shows a tick and wordmark, shield is the flat two-part style used by build badges, compact is the smallest."

addedInput schema / properties / theme / description

Added value: +"Colour scheme to match the page it will sit on."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "host": {
+      "type": "string"
+    },
+    "html": {
+      "description": "Ready-to-paste anchor and image markup.",
+      "type": "string"
+    },
+    "imageUrl": {
+      "description": "Live SVG badge; re-renders from a real audit every six hours.",
+      "format": "uri",
+      "type": "string"
+    },
+    "linkUrl": {
+      "description": "Full report the badge links to, so a visitor can verify the score.",
+      "format": "uri",
+      "type": "string"
+    },
+    "markdown": {
+      "description": "The same badge for a README.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "host",
+    "imageUrl",
+    "html"
+  ],
+  "type": "object"
+}

First observedAug 18, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Beyond the readOnly/idempotent annotations, it discloses meaningful behavior: the SVG is live, refreshes every six hours, links to the full audit, and comes in two output formats. It doesn't mention whether generation requires a prior audit or whether calling it triggers one, which is the main undisclosed trait.

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?

Two sentences, front-loaded with the deliverable, followed by the rendering behavior and then the usage trigger. Dense and mostly waste-free, though the scope could be slightly tighter.

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?

With annotations and an output schema already covering safety and return shape, the description supplies the key runtime behavior (live refresh, backlink). The one real gap is the prerequisite question of whether a prior audit must exist for the "real measured score" to render.

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% with three enums fully documented, so the schema already carries parameter meaning. The description adds nothing about url, style, theme, or metric, so 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 names a specific verb and artifact — producing HTML/Markdown embed code for a badge — which is unmistakably distinct from the audit and scoring siblings. An agent can tell at a glance this generates display markup rather than running checks.

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 gives a clear triggering condition: "Use this when someone wants to display that their site was checked." There is no explicit exclusion or named alternative (e.g. use get_score to read the value, this to embed it), so it stops short of full routing guidance.

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

All Outrings Web Intelligence 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.

Resources

Need Help?