English profanity filter: find and censor swear words, incl. obfuscations. Word list, not AI.
Scored across 1 tool
There is only one tool, so there is no possibility of overlap, misselection, or confusion between tools. Its purpose (profanity detection in English text) is unambiguous and self-contained.
The single tool name check_profanity follows a clear verb_noun convention and is descriptive of the action performed. With only one tool there is no opportunity for naming inconsistency.
The server's scope is a single atomic operation, so one tool is a defensible, well-scoped surface rather than an artificially fragmented one. It is slightly thin only in that batch checking or configuration (e.g. custom word lists, other languages) could conceivably be exposed, but nothing is bloated.
The tool covers the domain well: detection with match terms, UTF-16 positions, censor output, whitelist handling, and documented limits. Minor gaps exist (no batch input, no non-English or user-supplied word lists), but these are workarounds an agent can handle by calling the tool repeatedly.
Detect English profanity in text (word list with leetspeak, look-alike letters, repeated letters, dotted/spaced letters and hidden characters handled) and return the matched terms, their positions (UTF-16 start/end in your text) and, unless censor is false, a censored copy of the same length. Common innocent words (Scunthorpe, cockpit, Shiite, cumin) are whitelisted; it does not understand context and is English only. Text up to 10240 UTF-8 bytes; it is not stored or logged. matches is capped at 50 here (match_count is the full total). Read-only. Same engine, keys and limits as POST /v1/check.
| Name | Required | Description | Default |
|---|---|---|---|
| deny | No | Extra words to flag on word boundaries, e.g. ["jerk"]. | |
| text | Yes | The text to check, at most 10240 UTF-8 bytes. | |
| allow | No | Words never to flag, e.g. ["hell", "damn"]. Allow wins over deny. | |
| censor | No | Return a censored copy (default true). |
| Name | Required | Description |
|---|---|---|
| terms | Yes | |
| engine | No | |
| matches | Yes | Matches in text order, at most 50 here (see match_count for the total). start/end are UTF-16 indices into your text. |
| version | No | |
| censored | No | Your text with each match replaced by asterisks (same length). Omitted when censor is false. |
| truncated | No | True when matches lists fewer than match_count (over 50 here, or the API's own cap). |
| text_bytes | No | |
| match_count | Yes | Total number of matches in the text (not capped). |
| has_profanity | Yes | |
| matches_returned | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description still adds substantial non-obvious behavior: text is not stored or logged, matches is capped at 50 while match_count is the full total, and a censored copy of equal length is returned unless censor is false. These are exactly the traits an agent cannot infer from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence front-loads the core purpose before limitations, followed by tight constraint and privacy clauses. It is long but nearly every clause carries information; minor readability cost from the parenthetical enumeration of engine features.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained, yet the description still discloses limits, privacy handling, whitelist behavior, and result capping. For a read-only detection tool with no siblings, nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 all four parameters (including deny/allow precedence and the censor default), putting the baseline at 3. The description adds useful context on whitelisting and output-length behavior but does not clarify the deny/allow parameters themselves beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb and resource ('Detect English profanity in text') and immediately scopes the engine's capabilities (leetspeak, look-alike letters, hidden characters). An agent knows exactly what this tool does without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No sibling tools exist, so routing is moot, but the description gives clear operating context: English only, no contextual understanding, whitelisted innocent words, and 'Same engine, keys and limits as POST /v1/check.' It does not state explicit when-not-to-use conditions, but the limitations paragraph functionally bounds usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_profanityShould I allow this text? Profanity and toxicity checks that are hard to fool, with the evidence.
Detects and redacts PII (emails, phones, SSNs, names, addresses) from text. $0.02/call via x402.
Detect and redact PII and secrets before text reaches an LLM, with reversible placeholders.
Pay-per-call profanity/explicit-content detection for AI agents. $0.005 USDC per call, no signup.
Add one secure layer between your agents and this server.