mcp-codex-allowlist
Related Servers
Alternatives to mcp-codex-allowlist
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityBmaintenanceEnables autonomous coding agents to just-in-time retrieve scoped architecture contracts and task-specific P0/P1 rules before reading or writing files, record troubleshooting findings from test failures, revoke or downgrade stale short-term rules, propose long-term contract changes for human approval, and list active rules per project and task. Supports multi-project and multi-worktree workflows over MCP with SQLite-backed storage.1MIT
- AlicenseAqualityFmaintenanceEnables agentic coding clients to enforce portable policy guardrails by evaluating proposed shell, file write, git, and network actions and returning allow, deny, or ask decisions.2MIT
- AlicenseNot gradedqualityDmaintenanceProvides AI agents with queryable, version-controlled project rules and coding standards. Enables validation, rule-based guidance, and task summaries to keep AI work aligned with your project's conventions without repeating context.2MIT
- AlicenseNot gradedqualityBmaintenanceEnables MCP clients to read only explicitly allowlisted Linux project files and selected Codex conversation turns. It supports listing projects and files, reading UTF-8 files, bounded text search, and paged reading of authorized conversations.MIT
- FlicenseNot gradedqualityDmaintenanceEnables access to PolyAI Agent Studio Cursor rules via MCP tools for listing, retrieving, and searching rules, making them usable by any MCP-compatible client.-
- AlicenseNot gradedqualityCmaintenanceGives MCP clients a read-only, evidence-based view of explicitly approved local projects and individual Codex sessions, enabling codebase browsing, session review, and comparison of session records against current source and bounded Git history without modifying sources or controlling sessions.MIT
TDQS
Scored across 3 tools
get_global_exec_rules and get_local_exec_rules are distinct scopes, but get_codex_exec_rules is effectively a superset that reads both, so an agent can often just call the aggregate and the other two become redundant. Descriptions help clarify scope differences, but the boundary between 'both scoped reads' and 'combined read' invites miselection.
All three follow the same snake_case get_<scope>_exec_rules pattern, with only the scope token varying (global/local/codex). Fully predictable.
Three focused read tools are reasonable for an inspection-only rules surface, though the combined tool makes the set feel slightly redundant. Nothing extraneous, but arguably two tools would suffice.
The surface is read-only: no tools to add, modify, or remove allow/prompt/forbidden rules, and effective policy computation is explicitly disclaimed. For an allowlist server, the absence of any write or policy-resolution operation is a significant gap that will block manage-allowlist workflows.