Connections

Post a deal to Deal Flow

connections_deal_create

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 Deal Flow. 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. Posting a LIVE listing is part of a paid Pass plan (Pro carries 5 live listings, Business 20, Business Plus 50) - a free account's plan holds zero, so the reply returns an error naming the plan and https://pass.connections.icu instead of creating anything; 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

Name	Required	Description
`title`	Yes	One line naming the deal.
`region`	No	City or region. Optional, and it is what makes a listing findable by region.
`dry_run`	No	true previews the exact call and its outcome without creating or changing anything.
`publish`	No	true (default) makes the deal live now if every required field is present. false saves it as a draft.
`summary`	No	One or two sentences, shown on the marketplace feed.
`category`	No	e.g. 'real-estate', 'saas', 'services'. Optional, and it is what makes a listing findable by category.
`password`	No	Required when visibility is 'private' - the access password for the deal's page.
`visibility`	No	public (default) is listed on the marketplace. private needs `password` too and is reachable only by direct link.
`deal_intent`	No	Whether the member is selling/raising ('selling') or looking for capital, a partner or a buyer ('looking').
`capital_sought`	No	Optional amount being raised or asked.
`min_investment`	No	Optional minimum investment or ticket size.
`expected_returns`	No	Optional, free text.
`full_description`	No	The full pitch/details. Required to publish - with title, it is the whole publish requirement.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 8, 2026

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."

AddedSep 8, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only indicate mutating/non-destructive behavior, but the description adds significant behavioral detail: publish timing rules, paid-plan live listing limits, the specific free-plan error behavior, and dry_run's no-side-effect guarantee. This goes well beyond the structured annotations without contradicting them.

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 front-loaded with the usage trigger and uses four dense, purposeful sentences. Each sentence adds distinct information: when to use, creation/publishing behavior, plan limitations, and dry_run. There is no filler or redundancy.

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 creation tool with no output schema, the description covers the critical runtime behaviors an agent needs: success criteria, draft vs. live, plan gating, error behavior, and a safe preview mode. The remaining optional parameters are fully documented in the input schema, so nothing essential to invoking 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 coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining the publish/draft distinction, the exact title + full_description requirement for going live, and the plan-dependent outcome when publish is true. This is valuable parameter-level context not present in the schema alone.

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 opens with a specific verb and resource: 'post a deal' on Deal Flow, and enumerates exact member intents (list a raise, sell a business or asset, look for a partner/buyer/investment). It also states 'Creates one deal,' which clearly separates it from sibling list/read tools like 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?

It explicitly says 'Use this when the member asks to post a deal...' and adds conditional guidance for publishing vs. saving a draft, including the free-plan limitation. It does not explicitly name when not to use it or point to an alternative tool, but the context is clear enough for an agent to select it.

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

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