Laso Finance

upload_banking_document

Upload a proof-of-address document

Attaches a proof-of-address document to the banking application, for the cases where the partner asks for one. The application must already exist and have an individual on it, so complete the application first.

Two things reject uploads that otherwise look fine. A .jpg file must be sent as fileType: "jpeg" — "jpg" is refused. And the partner caps the decoded size at 10MB, even though their own upload page advertises 20MB; oversized files are rejected here before the round-trip.

fileContent accepts either a bare base64 string or a data: URL, so a browser FileReader.readAsDataURL result can be passed through unchanged.

Free.

Input Schema

Name	Required	Description
`country`	Yes	The document's country, ISO 3166-1 alpha-2.
`fileType`	Yes	The file's format. Send a .jpg as `jpeg`.
`filename`	No	The file's name.
`fileContent`	Yes	The file, base64-encoded. A `data:` URL is also accepted. Decoded size must be 10MB or less.
`documentType`	Yes	The kind of document.

Output Schema

Name	Required	Description	Default
`status`	No
`documentId`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 26, 2026

removedInput schema / properties / auth_token

Removed value: -{
-  "description": "Laso credential. Only if the MCP connection has no Authorization header.",
-  "type": "string"
-}

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "documentId": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "status": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

Changed1 schema field changedSep 26, 2026

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "documentId": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "status": {
-      "type": [
-        "string",
-        "null"
-      ]
-    }
-  },
-  "type": "object"
-}New value: +null

First observedSep 26, 2026

TDQS

A5/5.0

Behavior5/5

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

Beyond the annotations (which only indicate non-read-only, non-destructive), the description discloses two critical behavioral quirks: the .jpg must be sent as 'jpeg' and the decoded size limit is 10MB despite the partner's page advertising 20MB. It also explains fileContent accepts bare base64 or data URL. These are exactly the kind of hidden behaviors an agent needs to know.

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-organized: it opens with the purpose, then details prerequisites and behavioral caveats, then explains the fileContent flexibility. Every sentence earns its place, and the most critical pitfalls (jpg vs. jpeg, size cap) are surfaced prominently. No filler or repetition.

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 the tool has an output schema (not shown) and the input schema is fully covered, the description fills the essential gaps: prerequisites, format constraints, and size limits. An agent can call this tool correctly without needing additional information, making it complete for its complexity.

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?

Schema coverage is 100%, so all parameters are described. The description adds important nuances: it reinforces the jpg/jpeg mapping and the size constraint, and explains the flexibility of fileContent (data URL accepted). This adds meaning beyond the schema's basic field descriptions, helping the agent construct valid calls.

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 states a specific verb ('Upload') and resource ('proof-of-address document') and clarifies it attaches to an existing banking application. It clearly distinguishes this tool from siblings by its unique purpose, even though it doesn't name alternatives. The purpose is unambiguous and actionable.

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 mentions the use case ('for the cases where the partner asks for one') and gives a clear prerequisite: the application must already exist with an individual on it. It also instructs to complete the application first, providing concrete context for when to invoke this tool.

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

All Laso Finance tools Inspect

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

Need Help?