Skip to main content
Glama

Security advisor review

security_advisor

Consult a principal security engineer on a security topic.

Send specific code, a plan, a config, or a security question. For a full
codebase scan, use create_project and trigger_analysis. Choose one input:
content for small inline text, or content_document for a large design
document uploaded with prepare_file_upload. The upload keeps the file out
of the context window. Supplying both inputs is refused.

Use this selective consultation when feedback can still change a decision
about authentication, authorization, secrets, sensitive data, new network
exposure, cryptography, infrastructure, IAM, or filesystem or command
execution. Send the relevant plan or diff. Reserve calls for those
decisions, and respect a user's request to skip consultation.

The tool answers immediately from the content sent. Report it as an
advisory review of that content, with CRITICAL, HIGH, MEDIUM, or LOW
severity labels. Trent's full assessment requires a scan.

Each call starts a new conversation unless you pass thread_id. The
thread_id and resumed fields describe continuation.

A reply with detected_repository and onboarding_hint identifies a local
repository awaiting a Trent project. Say existing project findings were
unavailable to this review, and offer create_project.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "security_advisor"
  }
}

Input Schema

NameRequiredDescriptionDefault
contentNoPlan, code, config, or other content to review for security.
contextNoSecurity context, such as 'API behind Gateway auth, intentionally public endpoint'.
questionNoSecurity question to answer, such as 'Is this auth flow secure?'.
thread_idNoPass the thread_id from an earlier security_advisor call to continue with its full context. Use it to iterate on reviewed content, answer the advisor's question, or follow up on its findings. Omit it for a new topic. An unusable id starts a fresh conversation, reported in resumed.
project_nameNoTrent project name for relevant existing findings. Defaults to a match from the git remote.
content_documentNoName of an uploaded design document to review. Use this for a large file to keep it out of the context window. Call prepare_file_upload with document_type='design_doc', transfer the file with upload_command, then pass document_name here. Choose this or content.
content_document_versionNoVersion of the uploaded document, returned as document_version by prepare_file_upload. Defaults to the latest.

Output Schema

NameRequiredDescriptionDefault
errorNoTrue when the call itself failed. False for successful calls, including a scan still running, an already approved plan, or a repository classified as non-agentic. The reason field describes these workflow states.
reasonNoA stable snake_case code from the allowed set. Present on every error and on successful calls that carry a workflow state.
reviewNoSecurity review content returned by Trent.
messageNoExactly one sentence written for the user. Never raw exception text or a backend error string, which may expose private details.
resumedNoTrue when the supplied thread_id continued the conversation. False for a fresh conversation, including one started after an unusable thread_id.
metadataNoCaller metadata, such as 'expiration_warning'. Substantive results have their own fields. Never includes exception or backend error text, which may expose private details.
thread_idNoThis conversation's id. Pass it back as the thread_id argument to continue this same conversation on a later call.
next_stepsNoRecommended next actions, in order.
onboarding_hintNoGuidance for onboarding the detected repository into Trent.
detected_repositoryNoRepository auto-detected from the local git remote.
retry_after_secondsNoWith reason rate_limited, how many seconds Trent asks the caller to wait.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / retry_after_seconds
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "With reason rate_limited, how many seconds Trent asks the caller to wait.",
      +  "title": "Retry After Seconds"
      +}
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

The description adds substantial context beyond annotations: it says the tool answers immediately from the content sent, returns CRITICAL/HIGH/MEDIUM/LOW severity labels, starts a new conversation unless thread_id is passed, refuses both inputs, and special-cases detected_repository/onboarding_hint replies. With annotations already declaring it non-destructive and closed-world, these details give an agent the operational behavior it needs.

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 description is front-loaded with purpose and the full-scan alternative, then gives input-selection rules, usage scope, output behavior, and continuation semantics in a compact sequence. Every paragraph carries operational information needed to invoke the tool correctly.

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?

Given seven optional parameters, a rich schema, and an output schema, the description covers the remaining gaps an agent needs: when to choose this tool, how to choose between inline content and uploaded documents, how thread continuation works, and what to do with repository-related replies. No critical behavior for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful selection semantics for content versus content_document, explains the prepare_file_upload workflow for large documents, states that both inputs are refused, and clarifies thread_id continuation.

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: consult a principal security engineer on a security topic. It explicitly distinguishes this selective consultation from a full codebase scan by naming create_project and trigger_analysis as the alternatives.

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 clear when-to-use guidance for authentication, authorization, secrets, sensitive data, network exposure, cryptography, infrastructure, IAM, and filesystem or command execution decisions. It also says when not to use it by directing full scans to create_project and trigger_analysis, and by respecting a user's request to skip consultation.

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.