Skip to main content
Glama

MetaLend

by io.github.rabeles11

Verify SIWE signature and get a JWT

submit_auth_verify

Exchange a signed SIWE challenge message (from get_auth_challenge) for a JWT scoped to that wallet. The returned jwt must be passed explicitly as the jwt argument to submit_deposit/submit_withdrawal/submit_config for that same wallet — this server does not cache or store it. The JWT is only valid for the walletAddress that produced the signature; using it for a different wallet's write call will be rejected upstream. Reuse the same jwt for subsequent write calls to this wallet instead of re-authenticating every time — the response's expiresAt (decoded from the JWT's own exp claim) says how long it's good for. Rate limited to 5 calls/minute per caller, no more than one call every 12s.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainNoChain name, e.g. BASE, ETHEREUM, POLYGON. Defaults to ETHEREUM if omitted. For an EOA wallet this is irrelevant (signature recovery is chain-agnostic). For a smart-contract wallet, this MUST be the chain it has (or, if undeployed, would have via ERC-6492 counterfactual deployment) a valid signer on for this signature — it determines which chain's RPC is queried to validate it (ERC-1271/6492), and does not need to match the chain passed to get_auth_challenge.
signatureYespersonal_sign signature of the SIWE message from get_auth_challenge.
walletAddressYesEVM wallet address (0x-prefixed, 40 hex chars). Any casing is accepted — it is normalized to its EIP-55 checksum before being forwarded upstream.

Schema Changelog

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

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only say the call is not read-only and not destructive; the description carries the real behavioral burden and does so thoroughly: no server-side caching/storage of the JWT, strict per-wallet validity with upstream rejection for mismatched wallets, expiration via decoded exp, and a precise rate limit.

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 long but genuinely dense, with the key exchange purpose first and operational constraints following. A little repetitiveness around 'same wallet' exists, but each sentence contributes non-obvious information needed to use the tool safely.

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?

Despite the lack of an output schema, the description names the two response fields that matter for subsequent behavior (jwt and expiresAt) and covers the preconditions, downstream requirements, and rate limiting. There is no apparent gap that would prevent a competent agent from calling it correctly.

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

Parameters5/5

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

Though the schema already documents all three parameters (100% coverage), the description adds critical semantics: signature type is personal_sign, chain is irrelevant for EOAs but determines RPC validation for smart-contract wallets via ERC-1271/6492, and walletAddress is normalized to EIP-55 checksum. This materially improves correct invocation.

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 opens with a specific verb-resource pairing: exchange a signed SIWE challenge message for a JWT scoped to a wallet. It names the related get_auth_challenge and submit_* siblings, making the tool's position in the auth/write flow unambiguous.

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 explicitly ties this to get_auth_challenge as the source of the signed message and spells out that the JWT must be forwarded to submit_deposit/submit_withdrawal/submit_config. It also advises reusing the JWT instead of re-authenticating, and gives rate-limit constraints—clear operational guidance for when to call it.

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

All MetaLend toolsInspect
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

A4.5/5.0
Disambiguation5/5

Every tool targets a distinct operation: auth challenge/verify, config read/build/submit, deposit/withdrawal prepare/submit/status, balances, rewards, pools, and small utility lookups. Descriptions explicitly cross-reference one another (e.g., get_balances vs get_bridge_balances vs get_rewards), making accidental misselection very unlikely.

Naming Consistency5/5

Tool names follow a consistent snake_case verb_noun pattern: get_* for reads, prepare_* for signing-payload construction, submit_* for signed writes, and list_pools for the catalog. The verb families map cleanly onto the tool's lifecycle stages, so the naming is predictable and scannable.

Tool Count4/5

19 tools is on the higher end, but the count is justified by the domain: authentication, config lifecycle, deposit/withdrawal prepare-and-submit flows, status polling, balances, and reward reading each need dedicated surface area. A few utilities (get_token_info, get_transaction_costs, get_withdrawal_version) feel slightly granular, but none are redundant.

Completeness4/5

The tool set covers the core lifecycle well: auth, config creation/update, deposit, withdrawal, status tracking, balance/reward queries, and pool discovery. Minor gaps exist (no reward claim endpoint, no deposit/withdrawal history listing, no explicit rebalancer deletion), but the descriptions provide workarounds and clearly scope what is intentionally unsupported.

Resources