check_safety
Check text for harmful content using weighted keyword detection. Returns a 0–1 score and verdict (safe/caution/unsafe).
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
ai-guardrails
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the detection mechanism (weighted keyword detection) and the return format (0–1 score with a verdict), which adds behavioral context beyond the unannotated tool. However, it doesn't mention potential edge cases, thresholds, or side effects.
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?
Two short sentences with no filler. The first sentence explains the purpose and method, the second describes the output, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers purpose and return values, but it lacks usage context, such as when to prefer this tool over siblings, and omits any behavioral caveats. Hence it's minimally adequate.
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?
The schema has no field descriptions and 0% coverage, so the description must clarify the `text` parameter. It implicitly indicates that `text` is the content to be checked, but lacks details such as length limits or encoding requirements.
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?
Clearly states 'Check text for harmful content' with a specific verb and resource, distinguishing it from sibling tools like check_hallucination and detect_pii. The addition of 'using weighted keyword detection' clarifies the method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like full_check or detect_pii. The description implies its use for safety checking but does not mention exclusions or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A3.7/5.0
Disambiguation5/5
Each tool has a distinct role: hallucination scoring, safety classification, PII detection, combined checks, and redaction. The purpose of full_check as an aggregator is clear, so there is no harmful overlap.
Naming Consistency4/5
Tool names mostly follow a verb_noun pattern in snake_case (check_, detect_, redact_), which is consistent. The outlier full_check uses an adjective modifier but remains intuitive and readable.
Tool Count5/5
With five tools, the server is well-scoped for its purpose, covering detection, combined checking, and redaction without overwhelming users or leaving trivial gaps.
Completeness4/5
The core guardrail workflows—hallucination, safety, PII detection, and redaction—are covered, with full_check enabling batch processing. Missing advanced checks like prompt injection are minor gaps rather than critical omissions.