Skip to main content
Glama
cyberdroid2077

opsecforge-mcp

Redact text already in context

redact_text
Read-onlyIdempotent

Redact secrets in text you already have to create a safer copy for sharing in logs, tickets, or commits. Returns redacted text with a findings summary.

Instructions

Redacts secrets in text you ALREADY HAVE (for example before pasting logs into an issue, ticket, chat message or commit message) and returns the redacted copy with a findings summary. Honest limitation: the text you pass as the argument is already in the model context, and calling this tool does not remove it from there; it only produces a safer copy to share outward. To avoid putting a secret into the context at all, use redact_file with a path instead. Heuristic: can miss custom formats.

Input Schema

NameRequiredDescriptionDefault
textYesText to redact. NOTE: this text is already in your context; see the tool description.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare this as a safe, read-only, idempotent operation, but the description adds critical behavioral context: the input text is already in model context and calling the tool does not remove it. It also candidly warns that the heuristic can miss custom formats, which is exactly the kind of limitation an agent needs before trusting the output.

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 definition is front-loaded with the core action and return value, then adds the limitation, alternative, and heuristic in a tight sequence. Every sentence earns its place and there is no filler.

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?

For a one-parameter, read-only tool with no output schema, the description supplies everything an agent needs: what it does, what it returns, its key limitation, and the path-based alternative. No essential behavior or routing information is missing.

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?

Schema coverage is 100%, so the schema already documents the single text parameter. The description and schema both note that the text is already in the model context, but the description does not add format or syntax details beyond what the structured field already provides.

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 states a specific verb and resource: it redacts secrets in text already in context and returns a redacted copy with a findings summary. It clearly distinguishes itself from the sibling redact_file, which is the alternative for avoiding placing secrets into context at all.

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

Usage Guidelines5/5

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

It gives explicit use cases such as redacting before pasting logs into an issue, ticket, chat, or commit message. It also names the alternative and when to prefer it: use redact_file with a path to avoid putting a secret into context in the first place.

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