agentcard

get_settings

Read-onlyIdempotent

View the user's notification preferences (which email alerts they receive), their default payment source (which card or balance agents charge — check it before picking a funding source for them), their default delivery address (the wallet-level shipping address to use when buying physical goods for them — check it before asking them to dictate an address), and authorization settings (whether viewing card details or making transactions requires explicit approval). Authorization settings are read-only here; change the rest with the gated tool update_settings, calling it by name even though it isn't in the tools list.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`message`	Yes	Human-readable settings summary.
`authorization`	No	Authorization (approval) settings — read-only.
`notifications`	No	Email notification preferences.
`default_payment`	No	The wallet-level default payment source: { source: 'balance' } or { source: 'connected', connected_card_id }. null = auto (an active added card wins, else the balance).
`delivery_address`	No	The wallet-level default delivery address (street/city/state/zip + optional address2/phone/name), or null when unset.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed1 schema field changedAug 13, 2026

changedOutput schema / properties / default_payment / description

Previous value: -"The wallet-level default payment source: { source: 'balance' } or { source: 'connected', connected_card_id }. null = auto (an active attached card wins, else the balance)."New value: +"The wallet-level default payment source: { source: 'balance' } or { source: 'connected', connected_card_id }. null = auto (an active added card wins, else the balance)."

Changed1 schema field changedAug 8, 2026

addedOutput schema / properties / default_payment

Added value: +{
+  "description": "The wallet-level default payment source: { source: 'balance' } or { source: 'connected', connected_card_id }. null = auto (an active attached card wins, else the balance).",
+  "type": [
+    "object",
+    "null"
+  ]
+}

Changed1 schema field changedAug 7, 2026

addedOutput schema / properties / delivery_address

Added value: +{
+  "description": "The wallet-level default delivery address (street/city/state/zip + optional address2/phone/name), or null when unset.",
+  "type": [
+    "object",
+    "null"
+  ]
+}

First observedJul 28, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds valuable behavioral detail by specifying which settings are read-only (authorization settings) and that the rest can be changed via update_settings. It does not contradict annotations, and the practical guidance on using the returned data goes beyond what annotations provide, though it stops short of disclosing rate limits or pagination behavior.

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 long sentence with multiple clauses, but every clause adds substantive value: it enumerates the data returned, explains the practical importance of each, and points to the update tool. It is dense but not bloated, and the front-loaded 'View the user's notification preferences' immediately orients the reader.

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 that an output schema exists, the description need not enumerate return fields. It provides rich context about the meaning and use of each data category, states that authorization settings are read-only, and references the update tool. For a zero-parameter, read-only tool, this description is fully complete.

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 schema is empty. According to the rubric, a baseline of 4 applies. The description appropriately does not attempt to document nonexistent parameters; it focuses on the content of the read operation instead.

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 uses the specific verb 'View' and precisely enumerates the four categories of information returned: notification preferences, default payment source, default delivery address, and authorization settings. This clearly distinguishes it from sibling tools like get_balance or get_plan, and the additional context on how to use each piece of data reinforces the tool's purpose.

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?

The description explicitly instructs when to consult the tool ('check it before picking a funding source for them', 'check it before asking them to dictate an address') and names the alternative update_settings for modifying settings. This provides both concrete triggering conditions and an explicit alternative, fully satisfying the when-to-use vs. alternatives criterion.

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

All agentcard tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation4/5

Most tools have clearly distinct purposes, especially in areas like card management and shopping. However, the KYC flow has multiple overlapping tools (start_kyc, get_kyc_status, check_kyc_document, submit_kyc_document, submit_kyc_fields) that could confuse an agent despite detailed descriptions.

Naming Consistency4/5

Tool names consistently use snake_case with a verb_noun pattern (e.g., add_funds, create_card, list_cards). A few exceptions like surprise_me and whoami break the pattern but are still intuitive overall.

Tool Count3/5

50 tools is on the high side for a single server, but the broad domain (cards, shopping, KYC, support, settings) partially justifies it. Some tools could be merged (e.g., KYC flow tools) without losing clarity.

Completeness4/5

The tool surface covers core workflows: CRUD for cards, transactions, KYC, support, shopping, and account management. Minor gaps exist (e.g., no update_card general, no cancel order in shopping), but overall the set is comprehensive for the stated purpose.

Resources

Need Help?