B2B MCP server that lets business operators launch and operate complete branded taxi / food delivery / LP gas / on-demand apps from a single conversation. Multi-tenant, OAuth 2.1, 87+ active operators across 14 LATAM countries.
Scored across 5 tools
Descriptions work hard to separate the tools (explicit 'use THIS for install questions', 'do NOT call as a pre-step'), but cabgo_about returns the 'full product catalog' including pricing while cabgo_pricing also returns pricing, so those two overlap. Worse, cabgo_start_signup and cabgo_about both steer the agent toward tools that do not exist in this set (cabgo_create_trial, cabgo_create_my_app), suggesting actions the agent cannot actually take.
All names share a clean cabgo_ prefix, but the suffix conventions are mixed: verbs (get_publish_requirements, start_signup), bare nouns (pricing), and non-verbs (about, install_instructions). It is readable but not a predictable verb_noun pattern.
Five tools is a reasonable raw count, but for a server named 'Builder' the entire set is informational/onboarding reference content with no tool that actually builds or provisions anything, so the surface feels thin relative to its stated purpose.
The core lifecycle is missing: no create_app and no create_trial, even though other tools explicitly tell the agent to use those names, which will cause guaranteed dead ends. Only pre-sales/read-only operations (about, pricing, publish requirements, install, signup URL) are covered.
Public (no auth): describe what Cabgo is. Returns the full product catalog — what kinds of apps an operator can launch, pricing, who Cabgo is for, and how to onboard. Use ONLY when the user explicitly asks what Cabgo is, what it does, or wants an overview. Do NOT call this as a pre-step before cabgo_create_my_app — when the user wants to create / launch an app, go directly to cabgo_create_my_app without fetching context first.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=true), the description adds 'Public (no auth)' and states it returns the full product catalog. No contradictions with annotations, and it provides useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—two sentences plus a strong warning—with no wasted words. It front-loads the core purpose and includes critical usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema (implied), the description is complete. It covers the tool's purpose, target audience, return value, and circumscribes its use in relation to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters (empty object). Although no parameter descriptions are needed, the description effectively explains what the tool returns, which fully compensates. Baseline 4 is satisfied; the description adds context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: describes Cabgo, returns the full product catalog, and specifies conditions for use. It distinguishes itself from sibling tools like cabgo_create_my_app by explicitly stating when NOT to call it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: 'Use ONLY when the user explicitly asks what Cabgo is' and 'Do NOT call this as a pre-step before cabgo_create_my_app'. This clearly delineates when and when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public (no auth): returns the REAL operator checklist for publishing (most assets are auto-generated — bundle id, screenshots, descriptions, policies — so the operator only provides API access). For Play: invite console@cabgo.app + decide update-or-new + (if updating) upload keystore. For App Store: upload the API key alone (no invitation needed). Pass platform='android'|'ios'|'both' (default both).
| Name | Required | Description | Default |
|---|---|---|---|
| platform | No | Default 'both'. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds valuable behavioral context: it's public, returns a checklist, lists auto-generated items, and gives store-specific steps. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads key info (public, no auth), then explains the checklist, then store-specific steps. Every sentence adds value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has an output schema, the description need not explain return values. It fully explains what the tool does, including platform-specific requirements, making it complete for an agent to understand its use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'platform' is well-documented in the schema with enum and description. The description reiterates the options and default ('android'|'ios'|'both', default both), adding marginal clarity but not necessary given schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the operator checklist for publishing, distinguishes by platform (Play vs App Store), and lists auto-generated assets, making the purpose very specific and distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'Public (no auth)' and provides platform-specific instructions, implying when to use. While it doesn't list alternatives, the context from sibling names and tool purpose is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use THIS for any installation / setup / connection / 'how do I connect Cabgo' question, AND for any user who says they don't have a Cabgo account yet. Returns step-by-step instructions for (a) creating a Cabgo account at https://www.cabgo.app/empezar when needed and (b) installing the Cabgo MCP connector in the user's chat client (ChatGPT, Claude Desktop, Cursor). Trigger phrases: 'how do I install', 'how do I connect', 'how do I set up the connector', 'I don't have an account', 'I'm new to Cabgo', 'cómo instalo Cabgo', 'cómo me conecto', 'cómo creo cuenta', 'connect step by step', 'add this connector'. Pass client='chatgpt'|'claude'|'cursor'|'all'.
| Name | Required | Description | Default |
|---|---|---|---|
| client | No | Default 'chatgpt'. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description reveals it is a read-only instruction retrieval. Annotations show readOnlyHint=true, no contradiction. Adds details about account creation and installation steps, beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with bold headings and bullet-like structure. Front-loaded with key purpose. Slightly long but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers return value, use cases, parameter, and trigger phrases. With output schema present and annotations, the description is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has one parameter with enum and description. Description adds meaning by specifying default value and usage instruction ('Pass client=...'), enhancing the schema's coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is for installation/setup/connection questions and for users without an account. It specifies the return value (step-by-step instructions) and gives trigger phrases, differentiating it from sibling tools like pricing or account info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use THIS for any installation / setup / connection...', provides trigger phrases, and implies scope. Could be more explicit about when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public (no auth): informational pricing reference. Returns monthly SaaS subscriptions (Basic $15 / Professional $30 / Enterprise $70 per month, which INCLUDE 300 / 1,000 / 3,500 trips per month; trips above that quota are billed at $0.05 / $0.03 / $0.02 each (with standard maps or the tenant's own Google key; with high-precision Google Maps on Cabgo's shared key the included quota is divided by 6 and the overage rate multiplied by 6) — the monthly price is a floor, never quote it alone to an operator who has volume) and one-time app-build packages (Starter $399 Android-only, Pro $699 Android+iOS, Full $999 Android+iOS+source code). All plans include unlimited drivers / users / admins; Cabgo never takes a commission on the fare (the per-trip overage above is a quota charge, not a commission). Informational only. Do not generate or return a payment URL from this tool. When the operator wants to purchase, direct them to visit https://www.cabgo.app/empezar in their browser — all checkout happens on cabgo.app externally via Stripe, not inside this conversation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, and the description reinforces that with 'Public (no auth)' and '**Informational only.**' It adds substantial context beyond the annotations: no payment URL may be produced, checkout occurs externally via Stripe, and the monthly price is a floor that should not be quoted alone for volume operators.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the key framing ('Public (no auth): informational pricing reference') and the prohibitions are bolded for salience. The middle pricing section is dense with deeply nested parentheses (the high-precision Maps caveat), which costs some readability, but the detail is load-bearing for a pricing-reference tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no prose explanation. For a zero-param informational tool the description covers what it returns, the auth posture, the exact figures, and the required next step (route to cabgo.app for checkout) — nothing an agent needs is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so the baseline is 4; the description correctly spends no space on parameter syntax. It instead uses the space to explain the pricing semantics the agent must relay, which is the relevant 'parameter' equivalent for a no-input tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('informational pricing reference') and enumerates exactly what it returns: monthly SaaS subscription tiers and one-time app-build packages. An agent can distinguish this from siblings like cabgo_create_my_app, cabgo_start_signup, and cabgo_create_trial, which are action tools, without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly frames when to use it (informational reference for pricing questions) and when not to (do not generate or return a payment URL; direct purchasers to https://www.cabgo.app/empezar instead). It names the alternative purchase path and where checkout actually happens, 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.
Public (no auth): generate a signup URL for the operator who wants to pay first then configure (legacy flow). For the recommended chat-driven onboarding, use cabgo_create_trial instead — it spins up the tenant without payment so the operator can configure end-to-end in chat before deciding to activate. Use this tool only when the operator explicitly asks to pay before creating, or when targeting a marketing landing page rather than chat onboarding.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | No | BASIC | PROFESSIONAL | ENTERPRISE (monthly subscription) | |
| phone | No | WhatsApp phone in international format, e.g. +525500001234. | |
| source | No | Free-form attribution label for utm_campaign (e.g. 'claude-desktop'). | |
| appName | No | Name the operator wants for their app (rider-facing). | |
| appPlan | No | STARTER | PRO | FULL (one-time app build) | |
| country | No | ISO-3166-1 alpha-2 country code, lowercased. | |
| contactEmail | No | Operator email for attribution. | |
| productLines | No |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool is public (no authentication required) and is part of a legacy flow, which adds context beyond annotations. It does not specify the return format but an output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences, front-loaded with key information (no auth, legacy flow), followed by usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 optional parameters and an output schema, the description covers what it does, when to use it, and contrasts with an alternative. It is complete enough for an agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter descriptions in the schema cover 88% of parameters, so the description does not need to add much. It does not provide additional meaning beyond the schema, but the context of 'pay first' and 'legacy flow' helps frame the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a signup URL for a legacy 'pay first' flow. It distinguishes itself from the recommended sibling tool `cabgo_create_trial`, providing a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use (operator wants to pay first or targeting marketing landing page) and when not to use (prefer `cabgo_create_trial` for chat-driven onboarding). This provides clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
cabgo_create_my_appcabgo_create_trialcabgo_create_my_app2 fields changedInput schema / properties / brandConfirmedAdded value: +{
+ "description": "Only after a 409 brand_belongs_to_someone_else, and only if the operator confirms the name is really theirs (a surname, a city). Never set it on your own.",
+ "type": "boolean"
+}Input schema / properties / brandName / descriptionPrevious value: -"App brand shown to riders. e.g. 'Rappi Express', 'Taxi del Valle'."New value: +"App brand shown to riders. e.g. 'Pidelo Express', 'Taxi del Valle'. Must be the operator's OWN brand: a name containing another company's brand (Uber, DiDi, Rappi, Chevrolet…) gets 409 brand_belongs_to_someone_else — ask for another name."cabgo_about1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "data": {}
+ },
+ "required": [
+ "data"
+ ],
+ "type": "object"
+}cabgo_create_my_app1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "data": {}
+ },
+ "required": [
+ "data"
+ ],
+ "type": "object"
+}cabgo_create_trial1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "data": {}
+ },
+ "required": [
+ "data"
+ ],
+ "type": "object"
+}cabgo_get_publish_requirements1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "data": {}
+ },
+ "required": [
+ "data"
+ ],
+ "type": "object"
+}cabgo_install_instructions1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "data": {}
+ },
+ "required": [
+ "data"
+ ],
+ "type": "object"
+}cabgo_pricing1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "data": {}
+ },
+ "required": [
+ "data"
+ ],
+ "type": "object"
+}cabgo_start_signup1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "data": {}
+ },
+ "required": [
+ "data"
+ ],
+ "type": "object"
+}cabgo_aboutcabgo_create_my_appcabgo_create_trialcabgo_get_publish_requirementscabgo_install_instructionscabgo_pricingcabgo_start_signup
Add one secure layer between your agents and this server.