Skip to main content
Glama
Sign In

Supero

by io.github.supero-platform
OverviewDiscussions(2)Admin

build_recommend_integrations

Read-only

RECOMMEND which concrete provider integrations this app needs, and WHY — the deterministic Step-2 intelligence the web wizard uses, now over MCP. Pass the app description + the platform service_ids it will use (e.g. ['cart','order']); returns GROUPED, TIERED suggestions (required/recommended/optional) with the default option flagged — e.g. cart/checkout → a payment gateway (REQUIRED; stripe_checkout default, paypal/razorpay offered), customer-facing apps → transactional email, appointments+reminders → sms. Options are drawn ONLY from the LIVE installed manifests, so it can't suggest a provider you don't have. PRESCRIPTIVE complement to build_list_capabilities (which is descriptive): call this so you don't OMIT a needed integration; use build_list_capabilities for a service's exact id + config fields.

Input Schema

NameRequiredDescriptionDefault
regionNoOptional project region (ISO alpha-2, e.g. 'IN'). Decides the default payment gateway.
descriptionNoThe app description / intent (drives email/sms/oauth/ai/payment triggers).
service_idsNoPlatform service ids the app will use (e.g. ['cart','order','appointment']). Drives most recommendations.
project_uuidNoOptional project UUID; its region is used when `region` is not given.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / project_uuid
      Added value: +{
+  "description": "Optional project UUID; its region is used when `region` is not given.",
+  "type": "string"
+}
    • addedInput schema / properties / region
      Added value: +{
+  "description": "Optional project region (ISO alpha-2, e.g. 'IN'). Decides the default payment gateway.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true, so the description carries the real disclosure load — and it does: options are drawn ONLY from LIVE installed manifests (a hard constraint that shapes trust in results), the output is GROUPED/TIERED with a flagged default, and behavior is deterministic. It doesn't spell out what happens when no description or service_ids are supplied, which is the one remaining behavioral gap.

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 core action and the sibling differentiation; no filler sentences. It is dense with ALL-CAPS emphasis and stacked parentheticals, which costs a little readability, but every clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description still conveys the return shape (tiers, grouping, default flag) and the provenance of the options. The notable omission is behavior when the all-optional inputs are empty, which an agent might reasonably hit given zero required parameters.

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 coverage is 100% and the description's parameter notes largely restate the schema text ('region... decides the default payment gateway', 'service_ids... drives most recommendations'). The worked examples (cart/order → payment gateway, appointments → sms) add illustrative value but not new semantics per parameter.

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 ('RECOMMEND which concrete provider integrations this app needs') and immediately frames it as a deterministic Step-2 recommender. It explicitly contrasts itself with build_list_capabilities (prescriptive vs descriptive), so an agent can pick the right sibling without opening either schema.

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?

Gives a direct when-to-use rule ('call this so you don't OMIT a needed integration') and names the alternative for a different need ('use build_list_capabilities for a service's exact id + config fields'). It also tells the caller which inputs to pass to get useful output.

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

All Supero toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources