Skip to main content
Glama

Connections

by icu.connections
OverviewDiscussionsAdmin

Post a deal to Deals

connections_deal_create
Destructive

Use this when the member asks to post a deal, list a raise, sell a business or asset, or look for a partner, buyer or investment on Deals. Creates one deal. publish true (the default) makes it live immediately when title and full_description are both present; false saves a draft to finish later. A public listing is seen by everyone on the marketplace. Posting a LIVE listing needs a paid plan: on an account without one the reply says so instead of creating anything, and a draft can still be saved on any plan. Set dry_run true to see the exact call and outcome without creating anything.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYesOne line naming the deal.
regionNoCity or region. Optional, and it is what makes a listing findable by region.
dry_runNotrue previews the exact call and its outcome without creating or changing anything.
publishNotrue (default) makes the deal live now if every required field is present. false saves it as a draft.
summaryNoOne or two sentences, shown on the marketplace feed.
categoryNoe.g. 'real-estate', 'saas', 'services'. Optional, and it is what makes a listing findable by category.
passwordNoRequired when visibility is 'private' - the access password for the deal's page.
visibilityNopublic (default) is listed on the marketplace. private needs `password` too and is reachable only by direct link.
deal_intentNoWhether the member is selling/raising ('selling') or looking for capital, a partner or a buyer ('looking').
capital_soughtNoOptional amount being raised or asked.
min_investmentNoOptional minimum investment or ticket size.
expected_returnsNoOptional, free text.
full_descriptionNoThe full pitch/details. Required to publish - with title, it is the whole publish requirement.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / category / description
      Previous value: -"e.g. 'real-estate', 'saas', 'services'. Required to publish."New value: +"e.g. 'real-estate', 'saas', 'services'. Optional, and it is what makes a listing findable by category."
    • changedInput schema / properties / full_description / description
      Previous value: -"The full pitch/details. Required to publish."New value: +"The full pitch/details. Required to publish - with title, it is the whole publish requirement."
    • changedInput schema / properties / region / description
      Previous value: -"City or region. Required to publish."New value: +"City or region. Optional, and it is what makes a listing findable by region."
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare the safety profile (not read-only, destructive, non-idempotent, open world). The description adds substantial behavior the annotations cannot carry: publish defaults to live and requires title plus full_description, drafts save on any plan, live listings need a paid plan and fail with an explanatory reply rather than creating anything, public listings are visible to everyone, and dry_run previews without side effects.

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?

Front-loaded with the trigger phrase and then the publish/plan/dry-run semantics in tightly packed sentences. It is slightly dense at six sentences, but each carries distinct constraints rather than 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?

For a 13-parameter, non-idempotent mutation tool with no output schema, the description covers the essential gaps: default publish behavior, the live-listing paywall and its failure mode, draft fallback, visibility implications, and a dry_run escape hatch. An agent has what it needs to call it correctly.

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 a 3 is the baseline, but the description adds genuine cross-parameter meaning: publish only goes live when title and full_description are both present, and visibility/password/publish interact with the plan gating. It stops short of explaining region/category findability beyond what the schema already says.

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 (creates one deal on Deals) and enumerates the member intents that trigger it (post a deal, list a raise, sell a business, find a partner/buyer/investor), which cleanly separates it from the read-only sibling connections_deals_list.

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?

Gives explicit when-to-use triggers tied to user phrasing and explains the publish-true vs publish-false branch. It does not name a sibling alternative (e.g. connections_deals_list for browsing deals), so the routing guidance is clear but not exhaustive.

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

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