How do I use Sentinel?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Sentinel simulate $50 payment to Stripe for agent research-bot" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Sentinel

by bhavyam2

Overview Schema Related Servers Score Discussions

Python

Sentinel

A spend-policy and observability layer for Agentcard — declarative YAML policies, an enforcing MCP proxy, and an attribution/anomaly dashboard for AI agents that hold real (or sandbox) money.

The problem

Agentcard issues single-use virtual Visa cards to AI agents, and its own writing describes exactly how that should be governed:

"One card per task. Each task is a separate financial segment with its own card, its own budget, and its own blast radius." … "A task that should cost $12 gets a $15 card. Not a $100 card 'to be safe.'" — Financial Zero Trust for AI Agents

"Agent expense systems need to attribute spend to tasks, workflows, and agent identities." … "Set velocity thresholds based on your historical patterns and alert when they are exceeded." — AI Agent Expense Management

The product today ships numeric limits: a budget, a per-transaction cap, and a human-approval threshold. There is no merchant allowlist/denylist, no velocity limit, no time-window rule, no per-agent policy scoping, and no attribution or anomaly layer — teams are told to build those themselves. Sentinel is that missing layer, built the way the zero-trust post says it should work:

Policy engine — per-agent YAML rules (merchant allow/deny with wildcards, card velocity, allowed hours with timezones, per-card caps, daily budgets, approval thresholds) evaluated before any card exists, returning ALLOW / DENY / NEEDS_APPROVAL with a machine-readable reason chain of every rule checked, in order.
MCP proxy — a stdio MCP server that wraps Agentcard's MCP server. Every tool passes through unchanged except create_card and buy_checkout, which are policy-checked first. Every decision — including the denials Agentcard never sees — lands in a SQLite ledger with agent id, task id, and the full rule trace.
Observability — a webhook receiver joins Agentcard transaction events to the ledger, so every settled charge maps to agent → task → policy decision. One dashboard page: spend by agent and task, budget burn-down vs policy, the denied-spend log, and anomaly flags (daily-spend z-score, first-seen merchant, off-hours attempts).

Related MCP server: Bastion

60-second quickstart

git clone <this repo> sentinel && cd sentinel
./demo.sh        # creates a venv, seeds two agents, replays a scripted day,
                 # and serves the dashboard at http://127.0.0.1:8787/

No Agentcard account or credentials needed — the demo runs against a built-in mock that implements Agentcard's documented API shapes (see docs/NOTES.md). Then try the killer feature, a dry run that touches nothing:

.venv/bin/sentinel simulate --policy policies/example.yaml \
    --agent research-bot --amount 1800 --merchant OPENAI \
    --at "2026-07-15T23:30 America/Los_Angeles"

  ✓ merchant-deny        merchant 'OPENAI' matches no deny pattern
  ✓ merchant-allow       merchant 'OPENAI' matches allow pattern 'OPENAI'
  ✗ hours                local time 23:30 PDT is outside allowed window 06:00-22:00
  ...
Verdict: DENY

Exit codes: 0 ALLOW · 1 NEEDS_APPROVAL · 2 DENY. Add --json for machines, --state '{"spent_today_cents": 9000}'-style files for what-ifs, or --db sentinel.db to evaluate against real ledger history.

Architecture

flowchart LR
    subgraph agent side
        A[AI agent / MCP client]
    end
    subgraph Sentinel
        P[MCP proxy<br/>sentinel proxy]
        E[Policy engine<br/>policies/*.yaml]
        L[(SQLite ledger<br/>decisions + transactions)]
        O[Observe server<br/>webhooks + dashboard]
    end
    U[Agentcard MCP server<br/>mcp.agentcard.sh<br/>or built-in mock]
    W[Agentcard webhooks<br/>transaction.*]

    A -- "create_card / buy_checkout<br/>(+ agent_id, task_id)" --> P
    A -- "all other tools" --> P
    P -- "evaluate" --> E
    P -- "ALLOW → forward<br/>(sentinel args stripped)" --> U
    P -- "every decision,<br/>incl. denials" --> L
    W -- "signed events" --> O
    O -- "join to decisions" --> L
    O -- "dashboard :8787" --> A

Running it for real

Point the proxy at Agentcard (use a sandbox sk_test_-provisioned OAuth token; never start with live money):

cp .env.example .env    # fill in AGENTCARD_MCP_URL + AGENTCARD_TOKEN
sentinel proxy --policy policies/example.yaml --db sentinel.db

Register that command as the MCP server in your agent's config instead of Agentcard's — e.g. in claude_desktop_config.json / .mcp.json:

{
  "mcpServers": {
    "agentcard": {
      "command": "/path/to/.venv/bin/sentinel",
      "args": ["proxy", "--policy", "policies/example.yaml", "--db", "sentinel.db"],
      "env": { "AGENTCARD_MCP_URL": "https://mcp.agentcard.sh/mcp",
               "AGENTCARD_TOKEN": "…", "SENTINEL_AGENT_ID": "research-bot" }
    }
  }
}

Leave AGENTCARD_MCP_URL/AGENTCARD_TOKEN unset and the proxy uses the clearly-labeled mock — useful for CI and local development.

Run the observe server and register its URL as a webhook endpoint in the Agentcard dashboard (subscribe to transaction.*):
```
AGENTCARD_WEBHOOK_SECRET=whsec_… sentinel observe --policy policies/example.yaml --db sentinel.db
```

The proxy adds three optional arguments to the intercepted tools: agent_id and task_id (attribution, threaded into the ledger and joined to settled transactions) and merchant_hint on create_card — Agentcard's create_card has no merchant parameter (cards are open-loop until first charge), so the hint is the only pre-spend merchant control; it is checked against policy and stripped before forwarding. A NEEDS_APPROVAL verdict returns a hold; a human retries the call with sentinel_approved: true to release it. sentinel_approved can never override a DENY.

Policy reference

defaults:                      # applied to agents not listed (omit = unknown agents denied)
  max_per_card_cents: 1000

agents:
  research-bot:
    max_per_card_cents: 2500           # hard cap per card / checkout
    daily_budget_cents: 10000          # forwarded spend per local calendar day
    velocity: { max_cards: 5, per: 1h }  # trailing-window card-creation limit (s/m/h/d)
    merchants:
      allow: ["OPENAI", "ANTHROPIC", "AWS"]   # if present, everything else is denied
      deny: ["*GAMBLING*", "*CRYPTO*"]        # deny always wins over allow
    hours: { allow: "06:00-22:00", tz: "America/Los_Angeles" }  # overnight windows OK
    require_approval_over_cents: 1500  # NEEDS_APPROVAL above this

Rule precedence (first deny wins; the full chain is always reported): merchant-deny → merchant-allow → hours → velocity → max-per-card → daily-budget → approval-threshold. Merchant patterns are case-insensitive; */? are shell-style wildcards against the whole descriptor, and plain patterns match the descriptor prefix or any token prefix (OPENAI matches OPENAI *CHATGPT SUBSCR and PAYPAL *OPENAI).

Tests

.venv/bin/pytest --cov=sentinel.policy   # engine is 96%+ covered

143 tests cover rule precedence, wildcard matching, timezone/DST/overnight-window edges, velocity window boundaries, ledger joins and dedupe, webhook signatures against known HMAC vectors, and an end-to-end run of the proxy over a real in-memory MCP session.

What this doesn't do (honest edition)

It is not a network-level control. Sentinel gates what flows through its proxy. An agent holding raw Agentcard credentials — or a card number already minted — can spend without Sentinel ever knowing. Pair it with Agentcard's own budget/limit settings as the backstop; Sentinel is the fine-grained layer, not the outer wall.
Merchant rules on create_card are advisory-by-construction. Agentcard's API takes no merchant at card-creation time, so merchant_hint is only as truthful as the agent supplying it. The hint is still valuable (it's checked, logged, and auditable against the settled descriptor later), and buy_checkout merchant checks are real. Post-hoc, webhook descriptors expose any mismatch on the dashboard.
Merchant matching is string matching. AWS will not match a descriptor that reads AMAZON WEB SERVICES; card-network descriptors are messy. Write patterns against descriptors you've actually seen (the dashboard shows raw ones).
Approvals are honor-system at the MCP boundary. sentinel_approved: true is meant to be attached by a human-in-the-loop client, not the agent itself. If your agent framework can't guarantee that, treat NEEDS_APPROVAL as DENY.
Anomaly detection is deliberately simple (z-score with ≥3 days history, first-seen merchant, off-hours). A constant-spend history (σ=0) yields no z-flag; day one yields no flags at all. It's a tripwire, not a fraud model.
The live-API path is untested against production. Card/transaction operations are MCP-only (no public REST spec), and exercising the real server requires interactive OAuth onboarding — so CI runs against MockAgentcardClient, which mirrors the documented shapes in docs/NOTES.md. The policy engine, ledger, CLI, webhook receiver, and dashboard are fully real regardless of upstream.
Single-process ledger. SQLite (WAL) is plenty for one proxy + one observe server; it is not a multi-region audit store.

License

MIT — see LICENSE.

Available Tools

10 tools

buy_add_to_cartC

Add an item to the cart at a linked merchant.

ParametersJSON Schema

Name	Required	Description	Default
`item`	Yes
`merchant`	Yes
`quantity`	No
`price_cents`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only states the basic action without mentioning side effects (e.g., cart mutation), required prior steps, or that quantity defaults to 1 if omitted. The description is insufficient for understanding behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (7 words) but at the expense of necessary detail. For a tool with 4 parameters and no other documentation, it is under-specified and not appropriately sized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (4 parameters, no output schema, no annotations), the description is incomplete. It omits critical context like default quantity behavior, error conditions, and return values, making it inadequate for correct AI agent usage.

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

Parameters1/5

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

The description adds no meaning to the parameters beyond the schema structure. It does not explain 'merchant', 'item', 'quantity', or 'price_cents'. Schema coverage is 0%, so the description carries full burden but fails to clarify parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Add an item to the cart at a linked merchant.' It identifies the verb (Add) and resource (item to cart). However, it does not distinguish from sibling tools like 'buy_view_cart' or 'buy_checkout', lacking differentiation.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives (e.g., buy_view_cart, buy_checkout). There is no mention of prerequisites such as having a linked merchant or creating a cart first.

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

buy_checkoutA

Place and pay for the current cart at a linked merchant. [Sentinel: policy-enforced; may return status denied_by_sentinel or approval_required_by_sentinel with a machine-readable reason chain.]

ParametersJSON Schema

Name	Required	Description
`task_id`	No	[Sentinel] Task identifier threaded into the spend ledger.
`agent_id`	No	[Sentinel] Agent identity this spend is attributed to.
`merchant`	Yes
`tip_cents`	No
`approval_id`	No
`delivery_time`	No
`idempotency_key`	No
`sentinel_approved`	No	[Sentinel] Set true to resolve a NEEDS_APPROVAL hold (a human approved the spend). Never bypasses a DENY.

TDQS

A3.6/5.0

Behavior4/5

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

No annotations exist, so description carries full burden. It discloses that the tool is policy-enforced and may return specific statuses with machine-readable reason chains, indicating behavior beyond a simple purchase. This adds value without contradicting any annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is a single clear sentence followed by a brief Sentinel note. It is front-loaded and efficient, though it could be structured with bullet points for parameter details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 8 parameters, no output schema, and no parameter explanations in description, the description is incomplete. It doesn't mention expected return values (e.g., order confirmation) or error handling beyond the Sentinel statuses. More context is needed for an agent to use it effectively.

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

Parameters2/5

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

Schema description coverage is only 38% (low), and the description fails to explain any parameters beyond the Sentinel note. Parameters like merchant, tip_cents, delivery_time are not described, leaving the agent without context on their usage or format.

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?

Description states 'Place and pay for the current cart at a linked merchant', clearly identifying the action (place and pay), object (cart), and target (linked merchant). Distinguishes from sibling tools like buy_add_to_cart and buy_view_cart.

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

Usage Guidelines3/5

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

Describes Sentinel policy enforcement and possible returned statuses (denied_by_sentinel, approval_required_by_sentinel), giving context on when the tool may not succeed. However, lacks explicit guidance on when to use vs. alternatives like buy_add_to_cart or when to check cart status first.

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

buy_view_cartC

View the current cart at a merchant, with the priced total.

ParametersJSON Schema

Name	Required	Description	Default
`merchant`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

No annotations are present, so the description must fully disclose behavior. It indicates a read-only operation ('view') but does not mention authentication requirements, error conditions, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that conveys the purpose without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one parameter, no output schema, and no annotations, the description is minimal. It lacks details on return format, prerequisites (e.g., existing cart), and error handling.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds no meaning for the 'merchant' parameter beyond its name. The agent is not told whether this is an ID, name, or how to format it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool views the cart at a merchant and returns the priced total. It specifies the resource (cart) and action (view), but does not distinguish from siblings like buy_add_to_cart or buy_checkout.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as buy_add_to_cart or buy_checkout. The agent must infer usage from the name alone.

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

check_balanceB

Check the wallet balance.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, and the description fails to disclose any behavioral traits such as read-only nature, authentication requirements, rate limits, or side effects. For a simple query, more transparency is expected.

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 a single, front-loaded sentence with no wasted words. It is appropriately sized for a parameterless tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema and annotations, the description should clarify what the tool returns (e.g., 'Returns the current balance'). It only states the action without expected result, leaving the agent to infer.

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?

The tool has zero parameters, so the description does not need to add parameter semantics beyond the schema. Baseline score of 4 applies as per guidelines.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The verb 'Check' and resource 'wallet balance' clearly indicate the tool's purpose. It distinguishes from sibling tools which handle cards, transactions, and purchases, making the balance check unique.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like list_transactions (which might also show balance). No context for preferred usage or exclusions.

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

close_cardC

Deactivate a card.

ParametersJSON Schema

Name	Required	Description	Default
`card_id`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description minimally says 'deactivate' but fails to disclose whether the action is reversible, requires special permissions, or affects other cards.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (two words) and front-loaded, but could be slightly more informative without sacrificing brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema and no annotations, the description is incomplete—it omits return value, side effects, and additional context needed for correct invocation.

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

Parameters2/5

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

Schema description coverage is 0%, and the description adds no meaning to 'card_id' beyond its type, leaving the agent guessing about format or how to obtain it.

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 'Deactivate a card' uses a specific verb and resource, clearly distinguishing it from sibling tools like list_cards, create_card, and get_card_details.

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

Usage Guidelines2/5

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

No guidance is provided on when to deactivate a card versus other actions, nor any prerequisites or consequences mentioned.

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

create_cardB

Mint a new virtual card funded from the wallet. [Sentinel: policy-enforced; may return status denied_by_sentinel or approval_required_by_sentinel with a machine-readable reason chain.]

ParametersJSON Schema

Name	Required	Description
`type`	No
`task_id`	No	[Sentinel] Task identifier threaded into the spend ledger.
`agent_id`	No	[Sentinel] Agent identity this spend is attributed to.
`expires_at`	No
`amount_cents`	Yes
`scope_preset`	No
`merchant_hint`	No	[Sentinel] Intended merchant for this card, checked against the merchant allow/deny policy. create_card itself has no merchant argument, so this is the only pre-spend merchant control.
`sentinel_approved`	No	[Sentinel] Set true to resolve a NEEDS_APPROVAL hold (a human approved the spend). Never bypasses a DENY.

TDQS

B3.1/5.0

Behavior3/5

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

The description discloses important behavioral traits: policy enforcement and possible return statuses (denied_by_sentinel, approval_required_by_sentinel). However, it does not mention side effects like wallet deduction or idempotency, and no annotations are provided. The description is adequate but incomplete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise (one sentence plus a note), but it is under-specified given the tool's complexity (8 parameters, no annotations). It is not overly verbose, but the brevity sacrifices completeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lacks essential details: no success response, no explanation of parameter differences (e.g., single_use vs multi_use), and no information on expiration or scope_preset. With no output schema and no annotations, the description is insufficient for an 8-parameter creation tool.

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

Parameters2/5

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

The description adds no parameter-level information beyond the schema. With 50% schema coverage, the description fails to compensate for undocumented parameters like 'type', 'expires_at', 'amount_cents', and 'scope_preset'. The mention of 'funded from the wallet' loosely relates to 'amount_cents', but this is not explicit.

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 clearly states the action ('Mint a new virtual card') and the resource ('funded from the wallet'). It is specific and distinguishes from sibling tools, which are all list, check, close, or buy operations, so there is no ambiguity.

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

Usage Guidelines2/5

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

The description provides no explicit guidance on when to use this tool versus alternatives. While it implies creation, it does not mention prerequisites (e.g., wallet balance) or when other tools like 'check_balance' or 'list_cards' should be used instead.

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

get_card_detailsC

Retrieve full card number and CVV for a card.

ParametersJSON Schema

Name	Required	Description	Default
`card_id`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations, the description must fully explain behavior. It discloses that the tool returns sensitive data but fails to mention potential side effects, authorization requirements, or data sensitivity implications, leaving significant behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that directly states the tool's purpose. It is appropriately front-loaded and wastes no words, though it could benefit from additional context without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool retrieving sensitive data, the description omits critical details like output format, error cases, and security considerations. Even with low complexity, the lack of annotations and output schema demands more contextual information.

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

Parameters1/5

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

The input schema has 0% coverage for parameter descriptions, and the tool description does not clarify what 'card_id' is (e.g., format, source from 'list_cards'). The description adds no semantic value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the action ('Retrieve') and the specific resources ('full card number and CVV'), which distinguishes it from sibling tools like 'list_cards' or 'check_balance'. However, it does not specify the card type or usage context.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or warnings about sensitive data handling. The description lacks context such as requiring authorization or being used after listing cards.

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

list_all_transactionsB

List transactions across all cards.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are present, so the description carries full burden for behavioral disclosure. It does not mention read-only nature, rate limits, authentication requirements, or return format, which are important for a list endpoint.

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 a single, front-loaded sentence with no wasted words. It effectively conveys the tool's core function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema and annotations, the description is too brief. It does not explain what transaction details are returned or how this tool differs from the similar 'list_transactions' sibling, leaving gaps for an agent to infer.

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?

With 0 parameters and schema coverage at 100%, the description adds meaning by clarifying the scope ('across all cards'), which is beyond the empty schema. This helps the agent understand what data is being listed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'list', resource 'transactions', and scope 'across all cards', distinguishing it from the sibling 'list_transactions' which may be per card. However, it does not explicitly state the difference.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'list_transactions' or other sibling tools. The description does not mention intended use cases or exclusions.

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

list_cardsA

List cards created for this user.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It does not disclose whether the operation is read-only, safe, or any authentication or rate-limit behavior.

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 a single concise sentence with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool, the description is adequate but could specify what card details are returned. With siblings like list_all_transactions, more clarity would help.

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?

There are no parameters, so schema coverage is 100%. The description adds meaningful context by stating the action and scope.

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 clearly states the action (list cards) and the scope (created for this user). It distinguishes from sibling tools like get_card_details (single card) and create_card (creation).

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool versus alternatives such as list_transactions or get_card_details. The usage context must be inferred.

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

list_transactionsC

List transactions for a card.

ParametersJSON Schema

Name	Required	Description	Default
`card_id`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations exist, and the description only says 'list transactions', implying read-only. It fails to disclose details like transaction scope, ordering, pagination, or authentication needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, brief sentence which is efficient but lacks necessary detail. It is concise at the expense of completeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a simple tool with one parameter and no output schema, the description should clarify what transactions are returned and any filtering. It fails to do so, especially against sibling tools.

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

Parameters1/5

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

Schema coverage is 0% and description adds no meaning to the card_id parameter beyond its existence. No format, source, or validation hints are provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'list' and resource 'transactions' for a specific card. However, it does not differentiate from sibling 'list_all_transactions', which is a close alternative.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs list_all_transactions or any prerequisites. The description is purely functional without usage context.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

10 tool updatesv0.1.0Jul 28, 2026
- First observedbuy_add_to_cart
- First observedbuy_checkout
- First observedbuy_view_cart
- First observedcheck_balance
- First observedclose_card
- First observedcreate_card
- First observedget_card_details
- First observedlist_all_transactions
- First observedlist_cards
- First observedlist_transactions

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0

Disambiguation5/5

Each tool targets a distinct action: card management (create, list, close, get details), transaction queries (single card vs all), balance check, and purchasing flow (add to cart, view cart, checkout). The 'buy_' prefix clearly separates merchant actions from card operations, eliminating ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (e.g., list_cards, close_card, buy_add_to_cart). The only minor variance is 'check_balance' instead of 'get_balance', but it remains a clear verb_noun structure, maintaining high consistency.

Tool Count5/5

With 10 tools, the server covers the essential operations for virtual card management and merchant purchasing without being overwhelming. Each tool serves a necessary function in the workflow, making the count well-scoped for the domain.

Completeness3/5

The tool set covers core card lifecycle and basic transactions, but lacks merchant management (e.g., linking merchants), wallet funding, and cart modification (remove/update items). These gaps may cause agents to get stuck when the workflow requires actions outside the provided surface.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

IdentArk Gateway
io.identark
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
Security Agent Orchestration
29
agent-cost-allocator-mcp
io.github.CSOAI-ORG
Agent Cost Allocator MCP — multi-tenant LLM cost attribution for chargeback billing. Companion to
Finance Payments & Billing
2
sipi.bot — Spend Firewall for AI Agents
io.github.kindrat86
Pre-spend firewall for AI agents. Approves, blocks, flags transactions against policy rules.
Finance Security Autonomous Agents
2
shadowgate-mcp
io.github.josephibra
Security firewall for AI agents — scans MCP calls for injection, secrets, and risks.
Security Monitoring
2

Related MCP Servers

SentinelGateofficial
Security Agent Orchestration
Sentinel-Gate
A
license
Not graded
quality
A
maintenance
Open-source MCP proxy that enforces security policies, content scanning, and audit logging between AI agents and tool servers
Updated 5 months ago (2026-04-20 11:08 UTC)
25
AGPL 3.0
Bastion
Security Observability
SoumilBhandari
A
license
Not graded
quality
A
maintenance
A local-first control plane for AI agent tools, providing policy enforcement, spend caps, rate limiting, and audit trails for MCP servers.
Updated a month ago (2026-08-04 23:45 UTC)
1
Apache 2.0
ledgermind
Security Monitoring
cognis-digital
F
license
Not graded
quality
B
maintenance
Local LLM cost & token forensics proxy with anomaly detection, enabling security teams to scan for cost anomalies and abuse patterns, and expose results via MCP for autonomous agents.
Updated 2 months ago (2026-06-30 03:30 UTC)
-
gov-mcp
Security Autonomous Agents
liuhaotian2024-prog
A
license
Not graded
quality
C
maintenance
An MCP server that enforces runtime governance on AI agent actions — file access, command execution, delegation chains, and permission escalation.
Updated 4 months ago (2026-05-08 00:25 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bhavyam2/sentinel'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Sentinel

The problem

60-second quickstart

Architecture

Running it for real

Policy reference

Tests

What this doesn't do (honest edition)

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

SentinelGateofficial

Latest Blog Posts

MCP directory API