Skip to main content
Glama

Laso Finance

by finance.laso
OverviewDiscussionsAdmin

search_merchants

Search merchant spend data

Search Laso's merchant database for confirmed spend data for a given card type. Returns whether the card was accepted, not accepted, or unknown at each merchant.

Use card_type to search by the USA prepaid card (Non-Reloadable U.S., the default) or the international prepaid card (Non-Reloadable International). USA searches exclude merchants with non-US country-code TLDs; international searches do not.

Important: This database only contains merchants where Laso users have previously attempted a transaction. A merchant not being listed, or being listed as unknown, does NOT mean the card won't work there — it just means it hasn't been tried yet. If a merchant is listed as accepted, you can confidently use the card there. If listed as not_accepted, the card will fail at that merchant.

Banking and money-transfer merchants are always returned as not_accepted with a restriction_note, whatever the transaction history shows. Spending there counts as a transfer of value and is not supported on any card.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qYesSearch query — the merchant name to search for (e.g. "amazon", "netflix")
card_typeNoWhich card type to search acceptance for. Defaults to `Non-Reloadable U.S.` if omitted (preserves existing client behavior). Pass `Non-Reloadable International` to search for international prepaid card acceptance.Non-Reloadable U.S.
auth_tokenNoLaso credential. Only if the MCP connection has no Authorization header.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "card_type": {
-      "description": "The card type results are filtered for",
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "count": {
-      "description": "Number of merchants returned",
-      "type": [
-        "number",
-        "null"
-      ]
-    },
-    "merchants": {
-      "items": {
-        "description": "A merchant from the spend data database with its acceptance status for the Non-Reloadable U.S. card.",
-        "properties": {
-          "description": {
-            "description": "Brief description of the merchant",
-            "type": [
-              "string",
-              "null"
-            ]
-          },
-          "name": {
-            "description": "Merchant name",
-            "type": [
-              "string",
-              "null"
-            ]
-          },
-          "notes": {
-            "description": "Additional notes about using the card at this merchant",
-            "type": [
-              "string",
-              "null"
-            ]
-          },
-          "restriction_note": {
-            "description": "Present when the merchant is restricted rather than merely untested. Banking and money-transfer merchants are always reported as `not_accepted`, because spending there counts as a transfer of value. Approvals do occur at these merchants, so acceptance cannot be read off the transaction history. `null` for every other merchant.",
-            "type": [
-              "string",
-              "null"
-            ]
-          },
-          "status": {
-            "description": "Whether the Non-Reloadable U.S. card is accepted at this merchant. `accepted` = confirmed working, `not_accepted` = confirmed failing or restricted, `unknown` = card type not yet tried at this merchant. One of: accepted, not_accepted, unknown.",
-            "type": [
-              "string",
-              "null"
-            ]
-          },
-          "url": {
-            "description": "Merchant website URL",
-            "type": [
-              "string",
-              "null"
-            ]
-          }
-        },
-        "type": [
-          "object",
-          "null"
-        ]
-      },
-      "type": [
-        "array",
-        "null"
-      ]
-    },
-    "note": {
-      "description": "Important caveat about the data — this database only includes merchants where users have previously attempted transactions",
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "query": {
-      "description": "The search query that was used",
-      "type": [
-        "string",
-        "null"
-      ]
-    }
-  },
-  "type": "object"
-}New value: +null
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden — and it does so thoroughly. It discloses the database's limited coverage (only merchants previously attempted by Laso users), the treatment of banking/money-transfer merchants as always not_accepted with a restriction_note, and the TLD filtering behavior between card types.

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 well-structured and front-loaded: core purpose first, then parameter guidance, then critical caveats. Every sentence earns its place, and the markdown formatting makes the important caveat easy to notice.

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?

For a search tool with no output schema and no annotations, the description is unusually complete. It explains what the tool returns, how to interpret each possible status, the database limitation, and the special banking-merchant rule — so an agent can call it and act on the results without guessing.

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 value beyond the schema by explaining the card_type default, the difference between the two card_type values, and the country-TLD filtering consequence. The q parameter is adequately described in the schema.

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 and resource — 'Search Laso's merchant database' — and states the core output: whether a card was accepted, not accepted, or unknown at each merchant. This clearly distinguishes it from other search-family tools like search_docs and search_gift_cards.

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 tells the agent which card_type to use, explains the USA vs international behavior, and gives strong interpretation guidance: unlisted or unknown merchants do not mean failure, while accepted and not_accepted have definitive meanings. This equips the agent to decide when and how to use the tool correctly.

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

All Laso Finance toolsInspect
Try in Browser
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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources