Skip to main content
Glama

My matches

my_matches
Read-onlyIdempotent

For the signed-in client (the evaluating company): the notified matches of the latest completed assessment, or of the assessment named by assessment_id, best score first, each as a masked card with its score and tier. On a review account the cards are its matches, and no vendor is contacted. A vendor's contact details appear only on a match that vendor has accepted, with the requirement and preference credits that vendor earned for you and the status of each certification you required; every other card stays masked. No card carries pricing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
assessment_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusYes
matchesYes
summaryYes
verticalYes
pending_deliveryYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / vertical / enum
      Previous value: -[
      -  "tms",
      -  "dock-scheduling",
      -  "eld",
      -  "carrier-vetting",
      -  "fleet-management",
      -  null
      -]New value: +[
      +  "tms",
      +  "dock-scheduling",
      +  "eld",
      +  "carrier-vetting",
      +  "fleet-management",
      +  "supply-chain-procurement",
      +  "yard-management",
      +  null
      +]
  2. Changed2 schema fields changed
    • removedOutput schema / properties / boundary_statement
      Removed value: -{
      -  "type": "string"
      -}
    • changedOutput schema / required
      Previous value: -[
      -  "status",
      -  "vertical",
      -  "pending_delivery",
      -  "matches",
      -  "summary",
      -  "boundary_statement"
      -]New value: +[
      +  "status",
      +  "vertical",
      +  "pending_delivery",
      +  "matches",
      +  "summary"
      +]
  3. Changed2 schema fields changed
    • addedOutput schema / properties / matches / items / properties / reversed
      Added value: +{
      +  "type": "boolean"
      +}
    • changedOutput schema / properties / matches / items / required
      Previous value: -[
      -  "match_id",
      -  "masked_id",
      -  "total_score",
      -  "tier",
      -  "accepted",
      -  "vendor",
      -  "credits"
      -]New value: +[
      +  "match_id",
      +  "masked_id",
      +  "total_score",
      +  "tier",
      +  "accepted",
      +  "reversed",
      +  "vendor",
      +  "credits"
      +]
  4. Changed2 schema fields changed
    • addedOutput schema / properties / boundary_statement
      Added value: +{
      +  "type": "string"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "status",
      -  "vertical",
      -  "pending_delivery",
      -  "matches",
      -  "summary"
      -]New value: +[
      +  "status",
      +  "vertical",
      +  "pending_delivery",
      +  "matches",
      +  "summary",
      +  "boundary_statement"
      +]
  5. Changed2 schema fields changed
    • addedOutput schema / properties / matches / items / properties / credits
      Added value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "certifications": {
      +      "items": {
      +        "additionalProperties": false,
      +        "properties": {
      +          "label": {
      +            "type": "string"
      +          },
      +          "status": {
      +            "enum": [
      +              "met",
      +              "unmet",
      +              "not_assessed"
      +            ],
      +            "type": "string"
      +          }
      +        },
      +        "required": [
      +          "label",
      +          "status"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "preference": {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "requirement": {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    }
      +  },
      +  "required": [
      +    "requirement",
      +    "preference",
      +    "certifications"
      +  ],
      +  "type": [
      +    "object",
      +    "null"
      +  ]
      +}
    • changedOutput schema / properties / matches / items / required
      Previous value: -[
      -  "match_id",
      -  "masked_id",
      -  "total_score",
      -  "tier",
      -  "accepted",
      -  "vendor"
      -]New value: +[
      +  "match_id",
      +  "masked_id",
      +  "total_score",
      +  "tier",
      +  "accepted",
      +  "vendor",
      +  "credits"
      +]
  6. Changed2 schema fields changed
    • addedOutput schema / properties / summary
      Added value: +{
      +  "type": "string"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "status",
      -  "vertical",
      -  "pending_delivery",
      -  "matches"
      -]New value: +[
      +  "status",
      +  "vertical",
      +  "pending_delivery",
      +  "matches",
      +  "summary"
      +]
  7. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/closed-world annotations, the description discloses substantial behavioral rules: masking of cards, review-account behavior with no vendor contact, and the exact conditions under which a vendor's contact details, credits and certification statuses are revealed. It also explicitly states that no pricing is returned, which prevents a wrong assumption about payload content.

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 main retrieval behavior and ordering are front-loaded, and the remaining sentences each add a distinct rule (review accounts, contact disclosure, no pricing). It is dense and slightly run-on, but no sentence is filler.

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-value structure need not be documented, and the description instead supplies the semantics an agent needs: default scope, ordering, masking, and the disclosure conditions. Nothing required to call or interpret the tool correctly 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 description coverage is 0% for the single optional parameter, so the description carries the burden and does so: it explains that assessment_id selects a specific assessment and that omitting it falls back to the latest completed one. It stops short of specifying the UUID format or error behavior for an invalid id.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource and scope: the notified matches of the latest completed assessment, or of the assessment named by assessment_id, ordered best score first. It is clearly distinct from siblings like my_clients or my_scorecard_status, though it never explicitly contrasts itself with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the default behavior (latest completed assessment) and the condition that changes it (assessment_id supplied), which implies when the parameter applies. However, it names no alternative tool and gives no when-not-to-use guidance, so usage is inferred rather than stated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources