Sonar Connections

Show a personal event card

events_personal_card

Read-only

THE PERSONAL EVENT TOOL. Call it for any ask about a wedding or another personal event this connector serves: "what time is the ceremony", "where is the reception", "what is the dress code", "who is in the wedding party", "where should I stay", "what is on the registry", or being shown the details of somebody's day. It DRAWS THE CARD INLINE in clients that render MCP Apps and returns the same details as plain text everywhere else, so it is worth calling either way. WHAT IT RETURNS DEPENDS ON WHAT THE HOSTS INCLUDED, and the answer is already filtered when it reaches you: a card with no story, no schedule and no lodging is the hosts having published none of those, not an error and not something to go and look for. Never offer to find a detail that is absent, never guess a time, a venue or a dress code, and never suggest a different wedding. The reply names its source and the hosts; say that line. Accepts the event id or the event name.

Input Schema

Name	Required	Description	Default
`eventIdOrName`	Yes	Event id (test_wedding_a_garden) or the event NAME as the hosts spell it ("Susie and John").

Output Schema

Name	Required	Description	Default
`faq`	No
`kind`	No
`tabs`	No
`tier`	No
`brand`	No
`dates`	No
`error`	No
`found`	No
`hosts`	No
`links`	No
`people`	No
`places`	No
`source`	No
`tabbed`	No
`eventId`	No
`message`	No
`registry`	No
`schedule`	No
`personalType`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 11, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "anyOf": [
+    {
+      "required": [
+        "found",
+        "eventId",
+        "kind",
+        "personalType",
+        "tier"
+      ]
+    },
+    {
+      "properties": {
+        "ok": {
+          "const": false
+        }
+      },
+      "required": [
+        "ok"
+      ]
+    },
+    {
+      "properties": {
+        "found": {
+          "const": false
+        }
+      },
+      "required": [
+        "found"
+      ]
+    },
+    {
+      "required": [
+        "error"
+      ]
+    }
+  ],
+  "properties": {
+    "brand": {
+      "type": "object"
+    },
+    "dates": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "error": {
+      "type": "string"
+    },
+    "eventId": {
+      "type": "string"
+    },
+    "faq": {
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "found": {
+      "type": "boolean"
+    },
+    "hosts": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "kind": {
+      "type": "string"
+    },
+    "links": {
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "message": {
+      "type": "string"
+    },
+    "people": {
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "personalType": {
+      "type": "string"
+    },
+    "places": {
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "registry": {
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "schedule": {
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "source": {
+      "type": "string"
+    },
+    "tabbed": {
+      "type": "boolean"
+    },
+    "tabs": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "tier": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

AddedOct 10, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnly, non-destructive, closed-world), and the description adds substantially beyond that: conditional rendering in MCP Apps clients versus plain-text fallback, that absent story/schedule/lodging reflects host publication rather than failure, and that the reply carries a source/hosts line the agent should repeat. That is exactly the behavioral context annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The critical guidance is front-loaded, but the prose is padded with all-caps emphasis and overlapping prohibitions ('never offer to find a detail that is absent', 'never guess a time, a venue or a dress code', 'never suggest a different wedding') that restate one idea three ways. It is longer than the task requires.

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?

An output schema exists, so return shape needn't be spelled out, and the description still covers the variable-availability caveat an agent would otherwise misread as an error. Nothing needed to call a one-parameter, read-only card tool correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100% and the single parameter already documents both accepted forms with an example ('test_wedding_a_garden' / "Susie and John"). The description's closing line 'Accepts the event id or the event name' merely restates the schema, so the baseline 3 applies.

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 states a concrete verb and resource ('DRAWS THE CARD INLINE ... and returns the same details as plain text'), and scopes it to weddings and personal events this connector serves. It does not, however, distinguish itself from near siblings such as events_get, events_floor_card or events_overview, so an agent must infer which event tool to pick.

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

Usage Guidelines4/5

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

It gives concrete trigger phrasings ('what time is the ceremony', 'where is the reception', 'what is on the registry') and says it is worth calling even where the card cannot render. It sets clear exclusions ('never suggest a different wedding', 'never offer to find a detail that is absent') but never names an alternative tool for the cases it excludes.

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

All Sonar Connections 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?