Skip to main content
Glama
jagmarques

asqav-mcp

by jagmarques
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
ASQAV_API_KEYYesYour Asqav API key used for authentication.
ASQAV_API_URLNoThe Asqav API URL (optional, defaults to https://api.asqav.com).https://api.asqav.com

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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
check_policyC

Check if an action is allowed by the organization's policies.

Args:
    action_type: The action to check (e.g. "data:read:users", "api:external:call")
    agent_id: Optional agent ID to check policies for
preflight_checkA

Combined agent-status + policy-allowed check; returns CLEARED / NOT CLEARED summary.

Fail-open: a per-check exception is recorded as a warning, not a blocker.

Args:
    agent_id: The agent ID to check
    action_type: The action to check (e.g. "data:read", "api:call")
sign_actionB

Create a signed audit record for an AI agent action.

Args:
    agent_id: The agent performing the action
    action_type: Type of action (e.g. "data:read", "api:call")
    action_id: Unique identifier for this action
    payload: Optional JSON payload describing the action details
    compliance_mode: When True, mint a Compliance Receipt by sending the
        hash-only wire envelope (hash + hash_algo + payload_size). Requires
        payload to be supplied so the cloud can resolve the payload_digest
        object form.
list_agentsA

List all registered AI agents in the organization.

get_agentB

Get details for a specific AI agent.

Args:
    agent_id: The agent ID to look up
verify_signatureC

Verify an existing signature by signature_id.

Args:
    signature_id: The signature ID to verify
verify_outputA

Verify a signature and confirm the signed payload's output_hash matches expected_output.

Use to detect post-sign tampering of an agent's reported result.

Args:
    signature_id: The signature ID (from complete_action or sign_action)
    expected_output: The output string to verify against the signed hash
gate_actionA

Pre-execution gate; signs the decision and returns APPROVED, DENIED, or PENDING_APPROVAL. After an APPROVED gate, call complete_action(gate_id, result) to close the bilateral receipt.

Args:
    action_type: The action to gate (e.g. "data:delete:users", "tool:execute:sql")
    agent_id: The agent requesting the action
    tool_name: Optional name of the tool being invoked
    arguments: Optional JSON string of the tool arguments
    risk_context: Optional description of why this action is risky
complete_actionA

Sign the outcome of a gate-approved action and bind it to the approval signature as a bilateral receipt (approval + outcome linked by gate_id).

Args:
    gate_id: The gate_id returned by gate_action when it approved the action
    result: A description or JSON string of the action's outcome
enforced_tool_callA

Strong-enforcement path: policy-check, optionally forward to tool_endpoint, then sign request+response as one bilateral receipt (or sign approval only and require complete_action to close).

Args:
    tool_name: Name of the tool to execute
    agent_id: The agent requesting the tool call
    arguments: Optional JSON string of tool arguments
    tool_endpoint: Optional HTTP endpoint to forward the approved call to
create_tool_policyA

Upsert a local tool enforcement policy used by gate_action and enforced_tool_call; evaluated in-process (no API hop) and tool_endpoint enables bilateral request+response signing.

Args:
    tool_name: Name of the tool to create a policy for
    risk_level: Risk classification - "low", "medium", or "high"
    require_approval: If true, high-risk tools need human approval before execution
    max_calls_per_minute: Rate limit (0 = unlimited)
    blocked: If true, the tool is completely blocked
    hidden: If true, the tool is invisible - not listed and treated as nonexistent
    tool_endpoint: Optional HTTP endpoint to forward approved calls to
list_tool_policiesA

List all active local tool enforcement policies.

delete_tool_policyB

Remove a local enforcement policy for a tool.

Args:
    tool_name: Name of the tool to remove the policy for
scan_tool_definitionA

Scan an MCP tool definition for prompt injection, hidden unicode, dangerous schema fields, typosquatting, and hardcoded secrets; returns a risk assessment.

Args:
    tool_name: The tool name to scan
    description: The tool description to scan
    input_schema: Optional JSON string of the tool's input schema
scan_all_toolsA

Scan every registered tool policy for typosquatting and hidden unicode; returns a per-tool risk assessment summary.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored across 15 tools

Disambiguation4/5

Most tools have distinct purposes, but verify_output and verify_signature are closely related, though their descriptions differentiate them (output hash vs. general signature). check_policy and preflight_check also overlap slightly, but preflight_check adds agent status checking.

Naming Consistency3/5

The majority of tools follow a verb_noun pattern (e.g., check_policy, create_tool_policy, list_agents), but exceptions like enforced_tool_call (adjective_noun_noun) and gate_action (noun_noun) break the pattern. The naming is readable but not perfectly consistent.

Tool Count5/5

15 tools cover policy management, enforcement, scanning, signing, and verification without feeling bloated. Each tool serves a specific function in the security workflow.

Completeness4/5

The tool set provides CRUD for policies (via upsert create), gating, enforcement, scanning, and verification. Minor gaps exist, such as no explicit agent creation/removal tools, but the core security audit workflow is well-covered.

Maintenance

ActivityActive
ResponsivenessSyncing

Resources