Skip to main content
Glama

PropertyList: Spanish Property MLS

by es.propertylist
OverviewDiscussionsAdmin

My pipeline

my_pipeline
Read-onlyIdempotent

List the cards on YOUR agency's CRM pipeline boards (Kanban), with each board's own stage names and card counts.

Boards: lead, buyer, seller, tenant, nurture (each card is a contact) and property (each card is a listing). Stage names are whatever the agency renamed them to, so read them from the reply rather than assuming.

Call with no pipeline for a summary of every board - use this to answer "what's in my pipeline?" or "how many buyers do I have?". Call with a pipeline for that board's cards, newest activity first.

This is the board view. For enquiries that have just arrived and have not been worked yet, use my_leads instead.

Returns the WHOLE agency's boards, not one agent's cards: CRM access belongs to the agency, not to a person. Requires a linked PropertyList account (or an agency API key); only ever returns the calling agency's own data.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoCards per stage. Counts are always the full stage total, whatever this is set to.
stageNoOnly cards in this stage. Match on the stage name as it reads on the board (case-insensitive); closed stages such as Won or Lost can be asked for by name. Optional.
pipelineNoWhich board. Omit for a summary of all of them.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
boardsNoThe summary of every board, when no pipeline was asked for.
stagesNoThat board's stages, each with its full count and up to `limit` cards, most recently updated first.
pipelineNoThe board asked for.
total_cardsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "boards": {
+      "description": "The summary of every board, when no pipeline was asked for.",
+      "items": {
+        "properties": {
+          "pipeline": {
+            "enum": [
+              "lead",
+              "buyer",
+              "seller",
+              "tenant",
+              "nurture",
+              "property"
+            ],
+            "type": "string"
+          },
+          "stages": {
+            "items": {
+              "properties": {
+                "count": {
+                  "type": "integer"
+                },
+                "stage": {
+                  "type": "string"
+                }
+              },
+              "required": [
+                "stage",
+                "count"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "total": {
+            "type": "integer"
+          }
+        },
+        "required": [
+          "pipeline",
+          "total",
+          "stages"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "pipeline": {
+      "description": "The board asked for.",
+      "enum": [
+        "lead",
+        "buyer",
+        "seller",
+        "tenant",
+        "nurture",
+        "property"
+      ],
+      "type": "string"
+    },
+    "stages": {
+      "description": "That board's stages, each with its full count and up to `limit` cards, most recently updated first.",
+      "items": {
+        "properties": {
+          "cards": {
+            "items": {
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "closed": {
+            "type": "boolean"
+          },
+          "count": {
+            "type": "integer"
+          },
+          "stage": {
+            "description": "The agency's own name for the stage.",
+            "type": "string"
+          },
+          "value_of_shown_cards": {
+            "description": "EUR, buyer, seller and tenant boards only.",
+            "type": "integer"
+          }
+        },
+        "required": [
+          "stage",
+          "count",
+          "cards"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "total_cards": {
+      "type": "integer"
+    }
+  },
+  "required": [
+    "total_cards"
+  ],
+  "type": "object"
+}
  2. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds context annotations cannot: the tool returns the WHOLE agency's boards rather than one agent's cards, CRM access belongs to the agency not a person, and only the calling agency's own data is ever returned. It also warns that stage names are agency-renamed and must be read from the reply rather than assumed.

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?

Front-loads the core purpose, then boards/stages, then usage branching, then the sibling alternative, then access scope. Each paragraph carries distinct information with no repetition of the name or title.

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?

With an output schema present, return values need not be explained, and the description still covers everything else an agent needs: board enumeration, stage-name variability, the summary vs. filtered call pattern, the my_leads alternative, and the account/auth prerequisite. Nothing material is missing.

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, but the description adds real semantics beyond the schema: it explains that stage names are user-renamed and should be read from the response, and reinforces the summary-vs-board behavior of omitting pipeline. It does not elaborate further on limit/stage beyond what the schema already states.

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?

States a specific verb and resource ('List the cards on YOUR agency's CRM pipeline boards (Kanban)') and immediately enumerates the six boards and what each card represents. It clearly distinguishes itself from the sibling my_leads by naming it and the distinct scenario it serves.

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?

Gives explicit when-to-use branching: call without pipeline for a summary of every board (with concrete example questions), call with a pipeline for that board's cards. It also names the alternative tool my_leads and the condition ('enquiries that have just arrived and have not been worked yet') that selects it, plus the prerequisite of a linked PropertyList account or agency API key.

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

All PropertyList: Spanish Property MLS 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