Sentinela
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| sentinela_detect_stackC | Detecta a stack de um projeto: linguagem, framework, ORM, banco de dados, auth provider, hosting. |
| sentinela_audit_fullB | Executa auditoria completa de segurança no projeto. Retorna AuditReport com todos os findings, score e checklist. |
| sentinela_audit_secretsC | Audita o domínio "secrets" (Seção 13). Retorna findings estruturados. |
| sentinela_audit_xssC | Audita o domínio "xss" (Seção 18). Retorna findings estruturados. |
| sentinela_audit_deserializationC | Audita o domínio "deserialization" (Seção 28). Retorna findings estruturados. |
| sentinela_audit_loggingC | Audita o domínio "logging" (Seção 22). Retorna findings estruturados. |
| sentinela_audit_error_messagesC | Audita o domínio "error-messages" (Seção 4). Retorna findings estruturados. |
| sentinela_audit_timingC | Audita o domínio "timing" (Seção 29). Retorna findings estruturados. |
| sentinela_audit_identityC | Audita o domínio "identity" (Seção 2). Retorna findings estruturados. |
| sentinela_audit_mutationsC | Audita o domínio "mutations" (Seção 2). Retorna findings estruturados. |
| sentinela_audit_dependenciesC | Audita o domínio "dependencies" (Seção 21). Retorna findings estruturados. |
| sentinela_audit_headersC | Audita o domínio "headers" (Seção 11). Retorna findings estruturados. |
| sentinela_audit_corsC | Audita o domínio "cors" (Seção 19). Retorna findings estruturados. |
| sentinela_audit_testsC | Audita o domínio "tests" (Seção 14). Retorna findings estruturados. |
| sentinela_audit_secrets_mgmtC | Audita o domínio "secrets-mgmt" (Seção 26). Retorna findings estruturados. |
| sentinela_audit_request_limitsC | Audita o domínio "request-limits" (Seção 32). Retorna findings estruturados. |
| sentinela_audit_idorC | Audita o domínio "idor" (Seção 6). Retorna findings estruturados. |
| sentinela_audit_mass_assignmentB | Audita o domínio "mass-assignment" (Seção 20). Retorna findings estruturados. |
| sentinela_audit_error_handlingC | Audita o domínio "error-handling" (Seção 31). Retorna findings estruturados. |
| sentinela_audit_uploadsC | Audita o domínio "uploads" (Seção 10). Retorna findings estruturados. |
| sentinela_audit_ssrfC | Audita o domínio "ssrf" (Seção 23). Retorna findings estruturados. |
| sentinela_audit_redirectsC | Audita o domínio "redirects" (Seção 24). Retorna findings estruturados. |
| sentinela_audit_rate_limitingC | Audita o domínio "rate-limiting" (Seção 5). Retorna findings estruturados. |
| sentinela_audit_authC | Audita o domínio "auth" (Seção 8). Retorna findings estruturados. |
| sentinela_audit_webhooksC | Audita o domínio "webhooks" (Seção 27). Retorna findings estruturados. |
| sentinela_audit_input_validationC | Audita o domínio "input-validation" (Seção 3). Retorna findings estruturados. |
| sentinela_get_rulesA | Consulta regras de segurança por categoria ou termo. Retorna seções relevantes do knowledge base. |
| sentinela_get_checklistA | Retorna checklist de segurança com status pass/fail baseado nos findings do último audit. |
| sentinela_generate_reportC | Gera relatório de segurança em Markdown a partir de uma auditoria completa. |
| sentinela_compare_reportsA | Compara dois AuditReports (antes vs depois). Mostra findings novos, resolvidos e evolução do score. |
| sentinela_suggest_fixC | Dado um finding (JSON), sugere código corrigido com exemplo prático para a stack do projeto. |
| sentinela_validate_fixB | Re-executa o analyzer de um finding específico para verificar se a correção foi aplicada com sucesso. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| audit | Executa auditoria completa de segurança no projeto e gera relatório detalhado com score |
| audit_category | Executa análise de segurança focada em uma categoria ou vulnerabilidade específica (ex: xss, secrets, auth, idor, ssrf) |
| fix_finding | Orienta a correção de uma vulnerabilidade e valida determinísticamente se o problema foi resolvido |
| checklist | Gera a matriz de conformidade com 24 itens de segurança e status pass/fail |
| security_rules | Consulta diretrizes arquiteturais de segurança e boas práticas da base de conhecimento |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 32 tools
The 24 domain audit tools each name a distinct security area, but several pairs have genuinely overlapping scopes: audit_secrets vs audit_secrets_mgmt, audit_error_messages vs audit_error_handling, and audit_identity vs audit_auth are easily confused. Worse, audit_identity and audit_mutations both claim '(Seção 2)', which signals an unclear boundary even within the server's own metadata. The audit_full vs individual audits split is reasonable, but the close pairs create real misselection risk.
Every tool uses the same sentinela_ prefix with a consistent snake_case verb_noun pattern (audit_*, get_*, generate_*, compare_*, suggest_*, validate_*, detect_*). The audit domain tools uniformly follow audit_<domain>, making the whole surface predictable. No mixed conventions or casing deviations.
32 tools is heavy and sits above the comfortable range. Most of the bulk comes from 24 near-mechanical per-domain audit tools that could arguably be a single parameterized audit call, though a security domain does have many legitimate areas. It is defensible but on the bloated side.
The lifecycle is well covered: stack detection, granular and full audits, rules lookup, checklist status, report generation, before/after comparison, fix suggestion, and fix validation. This is a coherent end-to-end workflow with no obvious dead ends. Only minor domain coverage questions remain (e.g. which sections are omitted), so it falls just short of perfect.