Skip to main content
Glama
deenesjakoruzh
auditsocials

AuditSocials Glossary MCP

Official
by auditsocials
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

AuditSocials Glossary MCP — 212 Werbe- und Plattformrichtlinien-Begriffe für KI

npm version npm downloads license: CC BY 4.0 DOI MCP

Ein Model Context Protocol (MCP)-Server, der KI-Assistenten ein autoritatives, offen lizenziertes Glossar der Social-Media-Werbe- und Plattformrichtlinien-Terminologie bietet – 212 Begriffe (CC BY 4.0) mit Abdeckung von Plattformrichtlinien, rechtlichen & regulatorischen Rahmenwerken (DSA, GDPR, FTC), Ad-Tech-Kennzahlen, Inhalts- & Kreativstandards, Datenschutz & Daten, branchenspezifischen Regeln sowie Durchsetzung & Risiko.

Lassen Sie KI-Assistenten Werbungskonformitätsbegriffe genau definieren und durchsuchen, mit Quellenangabe und einer persistenten URI bei jeder Antwort – anstatt regulatorische und plattformpolitische Fachbegriffe zu halluzinieren.

  • 📚 212 kuratierte Begriffe in 8 Kategorien – Plattformrichtlinie, Recht/Regulierung, Ad-Tech, Inhaltsstandards, Datenschutz, Branchenregeln, Durchsetzung & Risiko.

  • 🔗 Zitiert & persistent – jede Definition enthält eine Quell-URL und eine stabile w3id.org-URI; der Datensatz hat eine Zenodo-DOI.

  • 🆓 Kein API-Schlüssel, keine Konfiguration – das Glossar ist gebündelt und schreibgeschützt; einfach npx.

  • 🤖 Grundlage für RAG & Agenten – reduzieren Sie Halluzinationen bei DSA/GDPR/FTC- und Plattformrichtlinien-Terminologie.

Umfang: Nur Glossar. Der AuditSocials Policy-Tracker, die Enforcement-Intelligence und der Scanner werden nicht über diesen Server bereitgestellt. Für Live-Pre-Publish-Richtlinienprüfungen siehe den begleitenden AuditSocials Compliance MCP.

Tools

Tool

Beschreibung

glossary_define

Definiert einen Begriff nach Name oder Slug. Gibt die vollständige Definition, Kategorie, anwendbare Plattformen, verwandte Begriffe und persistente URI zurück.

glossary_search

Sucht nach Stichwort und/oder Kategorie. Gibt passende Begriffe mit kurzen Definitionen zurück.

glossary_list_categories

Listet Glossarkategorien mit Begriffsanzahlen auf.

Related MCP server: ProductBrain

Schnellstart

npx -y auditsocials-mcp

Kein API-Schlüssel und keine Konfiguration erforderlich – das 212‑Begriffe-Glossar ist gebündelt.

Client-Einrichtung

Kommuniziert über stdio mit MCP, funktioniert daher mit jedem MCP‑kompatiblen Client.

Claude Desktop / Claude Code – zu mcpServers hinzufügen:

{
  "mcpServers": {
    "auditsocials-glossary": {
      "command": "npx",
      "args": ["-y", "auditsocials-mcp"]
    }
  }
}

Cursor, VS Code, Windsurf, Cline, Continue, Zed und andere MCP-Clients – verweisen Sie sie auf den Befehl npx -y auditsocials-mcp (keine Umgebungsvariablen nötig).

Verwendung – Fragen Sie einfach Ihren Assistenten

  • "Definieren Sie 'Kontosperrung' mit dem AuditSocials-Glossar."

  • "Durchsuchen Sie das AuditSocials-Glossar nach DSA-Begriffen."

  • "Welche Kategorien gibt es im AuditSocials-Werbekonformitätsglossar?"

  • "Definieren Sie 'Shadow Ban' und listen Sie verwandte Begriffe auf."

Jede Antwort enthält die Definition, Kategorie, anwendbare Plattformen, verwandte Begriffe, eine Quell-URL und eine persistente URI – so zitiert Ihr Assistent, anstatt zu raten.

Was enthalten ist

212 Begriffe, die Folgendes abdecken:

  • Plattformrichtlinie – Werbe- und Community-Richtlinienkonzepte auf Meta, TikTok, LinkedIn, Google Ads, YouTube, X, Snapchat, Pinterest.

  • Rechtlich & regulatorisch – DSA, GDPR, FTC, COPPA und verwandte Rahmenwerke.

  • Ad-Tech & Kennzahlen – Begriffe zu Auslieferung, Attribution und Messung.

  • Inhalts- & Kreativstandards, Datenschutz & Daten, branchenspezifische Regeln und Durchsetzung & Risiko (Sperren, Einsprüche, Demonetarisierung, Shadow-Limiting).

Daten, Herkunft & Lizenz

Kuratiert von AuditSocials, einem Plattformrichtlinien-Intelligence-Dienst, der Richtlinienänderungen, Regulierungsmaßnahmen und Durchsetzungsentscheidungen auf acht sozialen Plattformen überwacht.

FAQ

Was ist das AuditSocials Glossary MCP? Ein MCP-Server, der KI-Assistenten ermöglicht, 212 offen lizenzierte Social-Media-Werbe- und Plattformrichtlinienbegriffe zu definieren und zu durchsuchen, mit Quellenangabe bei jeder Antwort.

Benötige ich einen API-Schlüssel? Nein. Das Glossar ist gebündelt und schreibgeschützt – führen Sie einfach npx -y auditsocials-mcp aus.

Warum sollte ich es anstelle der direkten Modellabfrage verwenden? Regulatorische und plattformpolitische Terminologie (DSA, GDPR, FTC, Demonetarisierung, Shadow Bans) kann leicht subtil falsch sein. Dies verankert Antworten in einem kuratierten, zitierten Datensatz mit persistenten URIs – ideal für RAG und Agenten.

Kann ich die Definitionen in meinem eigenen Produkt verwenden? Ja, unter CC BY 4.0 mit Namensnennung von AuditSocials (Link zur Quell-URL oder DOI).

Welche MCP-Clients funktionieren? Jeder stdio MCP-Client – Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, Cline, Continue, Zed und andere.

Links

Entwicklung

npm install
npm run export-glossary   # regenerate the bundled snapshot from source data
npm run build             # compile to dist/

Schlüsselwörter: MCP server, Model Context Protocol, Werbungskonformitätsglossar, Plattformrichtlinien-Terminologie, DSA-Glossar, GDPR-Begriffe, FTC-Werbung, Social-Media-Richtliniendefinitionen, Content-Moderation-Glossar, Regtech, Ad-Tech-Glossar, CC BY 4.0-Datensatz, RAG-Grundlage, KI-Definitionen.

Lizenz

Inhalt: CC BY 4.0 · © AuditSocials

Available Tools

3 tools
glossary_defineA

Define a social media advertising / platform-policy compliance term from the AuditSocials Compliance Glossary. Accepts a term name or slug (e.g. 'account suspension' or 'account-suspension'). Returns the full definition, category, applicable platforms, and related terms.

ParametersJSON Schema
NameRequiredDescriptionDefault
termYesThe term name or slug to define

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are provided, so the description carries full burden. It clearly implies a read-only lookup (returns a definition) with no side effects. The description does not mention errors, auth, or rate limits, but for a simple glossary lookup, the behavioral traits are sufficiently transparent.

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?

The description is two sentences long, front-loaded with the core purpose, and contains no extraneous information. Every sentence adds value, making it highly efficient.

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?

Given the tool's simplicity (single parameter, no output schema, no annotations), the description fully covers the necessary context: what it does, what input it expects with examples, and what the output contains. No important aspect is missing for a glossary lookup tool.

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?

The schema already describes the parameter ('The term name or slug to define') with 100% coverage. The description adds concrete examples ('account suspension' or 'account-suspension'), which aids the agent in formatting input correctly. This improves upon the baseline of 3.

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 clearly states the tool's action ('Define a term'), specifies the domain ('AuditSocials Compliance Glossary'), and provides examples of input format. It is distinct from sibling tools glossary_search (which likely searches) and glossary_list_categories (which lists categories), making the purpose unambiguous.

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

Usage Guidelines3/5

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

The description explains what the tool returns (definition, category, platforms, related terms), which helps an agent decide when to use it. However, it does not explicitly contrast with sibling tools or provide when-not-to-use guidance, leaving the decision partially implicit.

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

glossary_list_categoriesA

List the AuditSocials Compliance Glossary categories with the number of terms in each. Useful to understand the scope of the vocabulary.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries full burden. It correctly indicates a read-only operation (listing with counts) and adds context about grouping by category. The behavior is transparent and appropriate, though no details on potential pagination or output format are given.

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?

The description is two sentences with no wasted words. It front-loads the core action and then explains utility, perfect for quick agent parsing.

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?

Given no parameters, no output schema, and simple sibling context, the description is sufficiently complete. It explains the output (categories with counts) and its usefulness. Minor gap: no mention of sorting or hierarchical structure if applicable.

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?

The tool has zero parameters, so the description need not add parameter details. It compensates by explaining what information is returned (categories with term counts), adding meaning beyond the empty schema.

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 clearly states the tool lists glossary categories with term counts, using specific verbs ('list') and resources ('categories'). It distinguishes itself from siblings like glossary_define and glossary_search by highlighting the purpose of understanding vocabulary scope.

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

Usage Guidelines3/5

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

The description implies usage by noting it's useful for understanding vocabulary scope, but provides no explicit guidance on when to use this versus siblings. It lacks exclusions or context for tool selection.

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. 3 tool updatesv0.1.0
    • First observedglossary_define
    • First observedglossary_list_categories
    • First observedglossary_search
Deploy Server
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

TDQS

A4.2/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct and non-overlapping purpose: define a specific term, search by keyword, and list categories. There is no ambiguity about which tool to use for a given task.

Naming Consistency5/5

All tools follow the consistent pattern 'glossary_<verb>_<noun>' (glossary_define, glossary_search, glossary_list_categories). The naming is predictable and clearly conveys the action and resource.

Tool Count4/5

Three tools is a reasonable number for a focused glossary server. It covers the core operations without being too sparse, though a few more tools (e.g., list all terms) could be added without causing bloat.

Completeness4/5

The tool surface covers the essential workflows: discovering terms (search and categories) and retrieving detailed definitions. A minor gap is the lack of a tool to list all terms directly, but the search and category tools adequately enable discovery.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers