Skip to main content
Glama
deenesjakoruzh
auditsocials

AuditSocials Glossary MCP

Official
by auditsocials
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

AuditSocials Glossary MCP — 面向AI的212条广告与平台政策术语

npm版本 npm下载量 许可证: CC BY 4.0 DOI MCP

一个模型上下文协议 (MCP) 服务器，为AI助手提供权威、开放许可的社交媒体广告与平台政策术语表——212条术语 (CC BY 4.0)，涵盖平台政策、法律与监管框架 (DSA、GDPR、FTC)、广告技术指标、内容与创意标准、隐私与数据、行业特定规则以及执法与风险。

让AI助手能够准确定义和搜索广告合规术语，每条回复均附带来源归属和持久URI——不再对监管和平台政策术语进行幻觉式定义。

  • 📚 8个类别共212条精选术语——平台政策、法律/监管、广告技术、内容标准、隐私、行业规则、执法与风险。

  • 🔗 可引用且持久——每条定义均附带来源URL和稳定的w3id.org URI；数据集拥有Zenodo DOI。

  • 🆓 无需API密钥，无需配置——术语表已打包且只读；只需npx。

  • 🤖 为RAG和智能体提供事实依据——减少对DSA/GDPR/FTC及平台政策术语的幻觉。

范围： 仅限术语表。AuditSocials政策追踪器、执法情报和扫描器不通过此服务器暴露。如需实时发布前政策检查，请参阅配套的AuditSocials Compliance MCP。

工具

工具

描述

glossary_define

按名称或slug定义术语。返回完整定义、类别、适用平台、相关术语和持久URI。

glossary_search

按关键词和/或类别搜索。返回匹配术语及其简短定义。

glossary_list_categories

列出术语表类别及术语数量。

Related MCP server: ProductBrain

快速开始

npx -y auditsocials-mcp

无需API密钥，无需配置——212条术语表已打包。

客户端设置

通过stdio支持MCP协议，因此可与任何兼容MCP的客户端配合使用。

Claude Desktop / Claude Code——添加到mcpServers：

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

Cursor、VS Code、Windsurf、Cline、Continue、Zed及其他MCP客户端——指向npx -y auditsocials-mcp命令（无需环境变量）。

使用方法——直接询问您的助手

  • "使用AuditSocials术语表定义账号封禁。"

  • "在AuditSocials术语表中搜索DSA相关术语。"

  • "AuditSocials广告合规术语表包含哪些类别？"

  • "定义影子封禁并列出相关术语。"

每条回答均包含定义、类别、适用平台、相关术语、来源URL和持久URI——让您的助手引用而非猜测。

内容概览

212条术语涵盖：

  • 平台政策——Meta、TikTok、LinkedIn、Google Ads、YouTube、X、Snapchat、Pinterest的广告与社区准则概念。

  • 法律与监管——DSA、GDPR、FTC、COPPA及相关框架。

  • 广告技术与指标——投放、归因和衡量术语。

  • 内容与创意标准、隐私与数据、行业特定规则以及执法与风险（封禁、申诉、去变现、影子限制）。

数据、来源与许可证

由AuditSocials策划，这是一项平台政策情报服务，监控八个社交平台的政策变更、监管行动和执法决策。

常见问题

什么是AuditSocials Glossary MCP？ 一个MCP服务器，让AI助手能够定义和搜索212条开放许可的社交媒体广告与平台政策术语，每条回复均附带来源归属。

我需要API密钥吗？ 不需要。术语表已打包且只读——只需运行npx -y auditsocials-mcp。

为什么用它而不是直接询问模型？ 监管和平台政策术语（DSA、GDPR、FTC、去变现、影子封禁）很容易出现细微错误。这能将答案建立在经过策划、可引用且带有持久URI的数据集上——非常适合RAG和智能体。

我可以在自己的产品中使用这些定义吗？ 可以，在CC BY 4.0许可下，注明AuditSocials出处（链接来源URL或DOI）。

哪些MCP客户端可用？ 任何stdio MCP客户端——Claude Desktop、Claude Code、Cursor、VS Code、Windsurf、Cline、Continue、Zed等。

链接

开发

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

关键词： MCP服务器、模型上下文协议、广告合规术语表、平台政策术语、DSA术语表、GDPR术语、FTC广告、社交媒体政策定义、内容审核术语表、监管科技、广告技术术语表、CC BY 4.0数据集、RAG事实依据、AI定义。

许可证

内容：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