neonloops

Connectors: search

connectors_search

Read-only

Finds the apps a neonloops workflow can use and the app events that start one when something happens. One mode per call, by argument:

none: the connected apps with account ids, status, label and tools (one whose sign-in has finished is marked active);
query or category: the catalogue of about 1,000 apps, with slug, auth type and tool count;
toolkit: that app's actions with parameters (unknown slugs refused);
sentence: which event fits, as a verdict (use-this-trigger, connect-app, no-event-for-that, app-has-no-events or unknown) with ranked candidates. For use-this-trigger, workflows_edit sets the Start from the candidate, as its data argument says. Mixing modes is refused; pages return nextCursor. Connect an app with connectors_begin; add an action to a step with workflows_edit.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "connectors_search"
  }
}

Input Schema

Name	Required	Description
`apps`	No	With sentence: slugs of up to 5 apps to search for events, connected or not. Omit to search the apps this workspace has connected.
`limit`	No	Page size for the catalogue (default 20) or an app's actions (default 50); max 50.
`query`	No	Catalogue search, or with toolkit a filter on its actions: a case-insensitive part of a name or slug, e.g. gmail.
`cursor`	No	The previous page's nextCursor, for the catalogue or an app's actions. Omit for the first page.
`toolkit`	No	An app's slug, e.g. gmail: returns that app's actions with their parameter schemas. Their slugs are the ones a step's tools and connectors_begin's enabled_tools take.
`category`	No	Catalogue search: only apps in this category. Not with toolkit.
`sentence`	No	What should start a workflow, in the user's words: the 'when …' part, e.g. "when a new email arrives". Looked up on its own, without query, category, toolkit, cursor or limit.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 3, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description still adds real behavioral detail the annotations lack: unknown slugs are refused, mixed modes are refused, pages return nextCursor, and the sentence mode returns a fixed set of verdict values. It stops short of describing error shapes or rate behavior, so it is strong but not exhaustive.

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 mode list is front-loaded and bulleted, and every line carries information an agent needs to pick a mode. It is dense and the final routing sentence about connectors_begin and workflows_edit, while useful, slightly crowds an already long block, keeping it from a perfect score.

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 seven optional parameters, no output schema and no enums, the description carries the full burden and discharges it: it sketches each mode's return fields (account ids, status, label, tools; slug, auth type, tool count; parameters; verdict plus ranked candidates) and notes pagination. An agent could call this correctly on the first try.

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 would be 3, but the description adds the cross-parameter semantics the schema cannot express: which argument selects which mode, which combinations are invalid ('Not with toolkit'), and that the sentence mode ignores query, category, toolkit, cursor and limit. That is meaningful added meaning beyond the per-field text.

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 names a specific verb and resource ('Finds the apps a neonloops workflow can use and the app events that start one') and immediately enumerates the four lookup modes, so an agent knows exactly what this tool returns. It also separates itself from siblings by naming connectors_begin for connecting and workflows_edit for wiring a trigger.

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

Usage Guidelines5/5

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

Mode selection is spelled out per argument: 'none' for connected apps, 'query'/'category' for the catalogue, 'toolkit' for an app's actions, 'sentence' for trigger matching. The description states that mixing modes is refused and routes follow-up work to connectors_begin and workflows_edit, leaving nothing to inference.

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

All neonloops tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?