Conecto

Call a connected system

connect_call

Send one request to a connected system, inside its allowed calls: method, path (after the base address), query and a JSON body. Answers with the status, the content type and the body (JSON when it is JSON), up to 1 MB. Writes wait for the owner's approval by default (connect_preview shows what would be sent). A call to a system behind the firewall goes to the company's bridge: it answers 202 with a call_id, and account_get_call has the answer once the bridge sends it, usually within seconds. The first 10,000 calls a month are free, then $0.0003 for each started 10 seconds the system takes to answer, at most $0.0012; a call through a bridge is $0.0003. Costs $0.0003 for each started 10 seconds the system takes to answer ($0.0003 when it answers within 10 seconds; at most $0.0012 a call); nothing if it fails.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "connection": "<connection>",
      "method": "<method>",
      "path": "<path>"
    },
    "name": "connect_call"
  }
}

Input Schema

Name	Required	Description
`body`	No	A JSON body for POST, PUT and PATCH.
`path`	Yes
`query`	No
`method`	Yes
`connection`	Yes	The connection's name.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 28, 2026

TDQS

A4.3/5.0

Behavior5/5

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

With annotations already covering readOnly=false and openWorld=true, the description adds substantial behavior: approvals for writes, bridge 202 handling with call_id, response size limits, and cost structure. It does not contradict the annotations; destructiveHint=false is consistent with calls being scoped to allowed calls and potentially requiring approval.

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 opening is front-loaded and useful, but the cost explanation is duplicated almost verbatim at the end. That repetition wastes space in an otherwise behavior-rich description.

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 generic connected-system request tool with no output schema, the description covers the important missing pieces: response contents and size, async bridge behavior, approval flow, preview alternative, and pricing. An agent has enough context to invoke it correctly or route to the relevant sibling.

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 only 40%, so the description needs to compensate and does so partially by explaining that path is after the base address and that the request includes method, query, and JSON body. However, it adds little about connection resolution, query encoding, or body shape beyond the schema.

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 states a specific verb and resource: send one request to a connected system, scoped to its allowed calls. It also distinguishes the tool from connect_preview, which shows what would be sent, and from account_get_call for bridge results.

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 clear context for writes waiting on approval and explicitly points to connect_preview for previewing. It also tells the agent to use account_get_call for firewall/bridge responses, though it does not explicitly exclude using dedicated integration tools instead.

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

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