Skip to main content
Glama
deenesjakoruzh
auditsocials

AuditSocials Glossary MCP

Official
by auditsocials
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

AuditSocials Glossary MCP — 212 Advertising & Platform‑Policy Terms for AI

npm version npm downloads license: CC BY 4.0 DOI MCP

A Model Context Protocol (MCP) server that gives AI assistants an authoritative, openly‑licensed glossary of social media advertising & platform‑policy terminology — 212 terms (CC BY 4.0) covering platform policy, legal & regulatory frameworks (DSA, GDPR, FTC), ad‑tech metrics, content & creative standards, privacy & data, industry‑specific rules, and enforcement & risk.

Let AI assistants define and search advertising‑compliance terms accurately, with source attribution and a persistent URI on every response — instead of hallucinating definitions for regulatory and platform‑policy jargon.

  • 📚 212 curated terms across 8 categories — platform policy, legal/regulatory, ad‑tech, content standards, privacy, industry rules, enforcement & risk.

  • 🔗 Cited & persistent — every definition carries a source URL and a stable w3id.org URI; the dataset has a Zenodo DOI.

  • 🆓 No API key, no config — the glossary is bundled and read‑only; just npx.

  • 🤖 Grounding for RAG & agents — reduce hallucination on DSA/GDPR/FTC and platform‑policy terminology.

Scope: glossary only. The AuditSocials policy tracker, enforcement intelligence and scanner are not exposed through this server. For live pre‑publish policy checks, see the companion AuditSocials Compliance MCP.

Tools

Tool

Description

glossary_define

Define a term by name or slug. Returns the full definition, category, applicable platforms, related terms and persistent URI.

glossary_search

Search by keyword and/or category. Returns matching terms with short definitions.

glossary_list_categories

List glossary categories with term counts.

Related MCP server: ProductBrain

Quickstart

npx -y auditsocials-mcp

No API key and no configuration required — the 212‑term glossary is bundled.

Client setup

Speaks MCP over stdio, so it works with any MCP‑compatible client.

Claude Desktop / Claude Code — add to mcpServers:

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

Cursor, VS Code, Windsurf, Cline, Continue, Zed and other MCP clients — point them at the npx -y auditsocials-mcp command (no env needed).

Usage — just ask your assistant

  • "Define account suspension using the AuditSocials glossary."

  • "Search the AuditSocials glossary for DSA terms."

  • "What categories are in the AuditSocials advertising‑compliance glossary?"

  • "Define shadow ban and list related terms."

Each answer includes the definition, category, applicable platforms, related terms, a source URL and a persistent URI — so your assistant cites rather than guesses.

What's inside

212 terms spanning:

  • Platform policy — advertising & community‑guideline concepts across Meta, TikTok, LinkedIn, Google Ads, YouTube, X, Snapchat, Pinterest.

  • Legal & regulatory — DSA, GDPR, FTC, COPPA, and related frameworks.

  • Ad‑tech & metrics — delivery, attribution, and measurement terminology.

  • Content & creative standards, privacy & data, industry‑specific rules, and enforcement & risk (bans, appeals, demonetization, shadow‑limiting).

Data, provenance & license

Curated by AuditSocials, a platform policy intelligence service that monitors policy changes, regulator actions and enforcement decisions across eight social platforms.

FAQ

What is the AuditSocials Glossary MCP? An MCP server that lets AI assistants define and search 212 openly‑licensed social‑media advertising and platform‑policy terms, with source attribution on every response.

Do I need an API key? No. The glossary is bundled and read‑only — just run npx -y auditsocials-mcp.

Why use it instead of asking the model directly? Regulatory and platform‑policy terminology (DSA, GDPR, FTC, demonetization, shadow bans) is easy to get subtly wrong. This grounds answers in a curated, cited dataset with persistent URIs — ideal for RAG and agents.

Can I use the definitions in my own product? Yes, under CC BY 4.0 with attribution to AuditSocials (link the source URL or DOI).

Which MCP clients work? Any stdio MCP client — Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, Cline, Continue, Zed and others.

Links

Development

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

Keywords: MCP server, Model Context Protocol, advertising compliance glossary, platform policy terminology, DSA glossary, GDPR terms, FTC advertising, social media policy definitions, content moderation glossary, regtech, ad‑tech glossary, CC BY 4.0 dataset, RAG grounding, AI definitions.

License

Content: 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. Dates show when Glama detected each change.

  1. 3 tool updatesv0.1.0
    • First observedglossary_define
    • First observedglossary_list_categories
    • First observedglossary_search
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0
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

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/auditsocials/auditsocials-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server