Pedro Lopez, software engineer at Airbyte, discusses lessons from building two interfaces for AI agents to access company data through Airbyte's Context Store: an MCP server and a CLI. Both are thin interfaces over one platform built from OpenAPI specs. The MCP section covers keeping tool counts small with progressive discovery, OAuth as the realistic sign-in method, long-lived sessions, and why URL elicitation is not yet ready across clients. The CLI section covers designing for agents rather than humans: JSON input and output, consistent noun-verb commands, skills shipped with the tool, and no interactive prompts. The talk closes with guidance on when to choose MCP versus a CLI. Recorded at the AI Engineer World's Fair 2026 in San Francisco. The speaker's account is presented as experience-based lessons rather than independently verified benchmarks. # Channel Presentation Observations: Airbyte Engineering Talk ## Source Scope - **Video ID:** 01a15ca6-dc3f-7c0c-8df0-318b949f064b - **Title:** "Designing CLIs for Agents, Not Humans — Pedro Lopez, Airbyte" - **Available sources:** Title and transcript only. No curated metadata was supplied. - **Limitation:** These observations cover one talk. They do not establish channel-wide patterns. --- ## 1. Explicit Self-Description ### Speaker identity - The speaker introduces himself as a software engineer at the company. > "Uh my name is Pedro. I'm a software engineer at Airbet." The transcript renders the company name as "Airbet" and "Airbite." The title spells it "Airbyte." ### Company self-description (creator claims) - **Origin:** The company describes its history as starting from data movement. > "we started as the open- source uh, standard for data movement." - **Current positioning:** It describes its current role as a broader layer for AI agents. > "now we're using that same expertise and have evolved to being the data and action layer for your AI agents." - **Mission:** The stated goal is broad data availability. > "our goal is that we want to make data available and actionable everywhere." --- ## 2. Claimed Product Scope ### Interfaces offered The speaker lists three ways to access the **context store**: - **SDK:** for "building your own agents and your tools" - **Web UI:** described as "a quick way that you can use it through our web app" - **MCP and CLI:** the focus of this talk, described as "a way to easily make that available within existing agents like Chat GPT and Claude" ### Three stated capabilities The speaker says all interfaces should span: 1. **Resource management:** "manage all of the core resources of our product to our organizations workspaces and connectors" 2. **Secure authentication:** authenticating third-party services "in a way that's secure and doesn't expose your credentials to the AI agents" 3. **Ask and act:** "search across the context store" and "read and write and take action on all those systems" ### Architectural claims - The MCP and CLI are described as "thin unified interfaces into our platform, not reimplementations of the platform." - OpenAPI specs are described as "a source of truth for how to connect to our APIs." - The platform is said to change "over 10 times a day." --- ## 3. Intended Audience Audience is inferred from explicit statements about who each interface serves. - **Non-technical users:** > "MCPs are really great for users that might not be technical." - **Technical users:** > "CLI are kind of the more technical counterpart..." - **Agent builders and tool developers:** The SDK is framed for people "building your own agents and your tools." The lessons-learned section is framed for those "doing something similar." - **Developers designing agent-facing CLIs:** The CLI section opens with "design those CLIs with agents in mind." --- ## 4. Demonstrated Presentation Patterns These are observed in the talk itself, not stated as channel claims. ### Format - **Conference-style talk:** The speaker presents to an audience, uses a structured outline, and ends with a booth invitation. - **Live product demonstrations:** Two sequences show an MCP session in an AI client and a CLI session that loads a skill and queries the context store. - **Lessons-learned framing:** Sections are organized around design decisions and trade-offs. ### Evidence of candor about limits The speaker acknowledges constraints and open issues: - The Anthropic listing is still pending: "which we're still pending on if there's anybody from Enthropic out there that wants to approve us." - Client support is uneven: "the spec is not uniformly implemented across the board." - Elicitation was not used for credentials because of client support gaps: "we had to go back to doing our own thing." ### Closing call to action > "we have a booth over there at Airbite that you should check out and come work with us." --- ## 5. Creator Claims vs. Demonstrated Evidence | Claim | Type | Support in material | |---|---|---| | Airbyte is "the data and action layer for your AI agents" | Creator self-description | Stated in transcript | | MCP and CLI are thin layers over the platform | Architectural claim | Stated; not verifiable from the talk | | Context store combines data across Zendesk and Stripe | Demonstrated | Live MCP example shows cross-referencing to find five paying customers with open tickets | | Hosted MCP is "pretty trivial to install" | Creator claim | Stated; shown only through a brief installation description | | Listed on the ChatGPT app store | Creator claim | Stated; the listing is referenced but not independently shown | | Anthropic listing pending | Creator statement | Stated | --- ## 6. Limits of These Observations - No metadata was provided, so no channel description, subscriber information, or upload history is available. - These observations describe only this talk's presentation and should not be generalized to the channel or company without additional sources. - Transcript artifacts (for example, "Enthropic," "Chad GBT," "Zenes," "ooth") were interpreted as the obvious intended terms (Anthropic, ChatGPT, Zendesk, OAuth). # Delivery Observation — "Designing CLIs for Agents, Not Humans" (Pedro Lopez, Airbyte) ## Overall Delivery Style - **Conversational, demo-forward structure.** The talk alternates between explanation and live product walkthrough: *"Okay, so let's look at uh an example. This is our MCP in action."* - **Frequent verbal scaffolding.** Heavy use of fillers and connectors throughout: *"um," "uh," "you know," "kind of."* These appear in nearly every segment, indicating a casual, unscripted delivery rather than a memorized script. - **Self-corrections in real time.** At least one audible mid-sentence fix: *"this time with the the MCP or sorry, with the CLI."* ## Recurring Phrases and Vocabulary - **"So" as a segment opener** — used repeatedly to transition: *"So, Airbite's been around for a while," "So what exactly are we exposing," "So that's an example for uh the the enthropic."* - **"Cool." as a closing beat.** Used to wrap up sections: *"Cool. So let's go into kind of some lessons learned," "Cool. Elicitation though is not the way," "Cool. And then another interesting fact."* This is a consistent, observable verbal tic. - **"Lessons learned" framing.** The talk is explicitly organized around practical takeaways: *"let's go into kind of some lessons learned while building this uh MCP and things that you might want to keep in mind if you're doing uh something similar."* - **Numbered lesson delivery.** Sections are enumerated aloud: *"So one thing that we decided to do," "Two, Olaf is the way," "Two consistency is very much key here," "Three, skills are skills ship with uh the CLI tool."* - **Agent-centric vocabulary.** Consistent terms: *"progressive discovery"* (used at least twice), *"context store," "thin unified interfaces," "context," "contract," "expose/exposing."* - **Emphatic verdict phrasing.** Declarative "X is/is not the way" constructions: *"Two, Olaf is the way"* and *"Elicitation though is not the way."* ## Teaching Habits - **Paired examples for contrast.** The same task is demoed twice — once via MCP, once via CLI — so the audience can compare: *"which connectors do I have available?"* followed by *"show five paying customers with Zenes support tickets"* in both demos, explicitly flagged: *"Same as last time."* - **Trade-off framing.** Recommendations are consistently presented with counterpoints rather than absolutes: *"Well, they both have kind of their own trade-offs,"* followed by limitations of both MCP (2 KB description limits, run-time limits) and CLI (versioning, update burden). - **Rule-then-reasoning pattern.** Each lesson is stated as a directive, then justified: *"keep the tool count small. So um we... only expose or really deal with two main tools."* - **Practical fallback advice.** Encourages observing agent behavior as a design signal: *"if you see agents making the same mistake over and over... consider making that your contract."* ## Communication Patterns - **Direct audience address.** Occasional second-person engagement: *"Hey, I have four connectors set up"* (voicing the agent), *"anybody from Enthropic out there that wants to approve us."* - **Closing call to action.** Ends with a promotional beat: *"we have a booth over there at Airbite um that you should check out and come work with us. Thanks."* ## Stable Patterns vs. Isolated Moments **Stable (repeated):** - "Cool." section-closers (3+ occurrences) - Numbered lesson structure ("one... two... three") in both the MCP and CLI sections - Filler density ("um"/"uh"/"you know") throughout - Trade-off framing for every recommendation **Isolated (single occurrences, not treated as patterns):** - The self-correction *"or sorry, with the CLI"* - The joke aimed at Anthropic reviewers (*"if there's anybody from Enthropic out there"*) - The transcript contains apparent transcription artifacts ("Airbet," "Airbite," "Chad GBT," "Zenes," "Enthropic") — these are treated as transcription noise, not deliberate delivery choices. ## Uncertainty Notes - Tone inference beyond the observable (e.g., confidence level, nervousness) is not asserted; fillers are noted only as a measurable frequency pattern. - Whether the numbered lessons are slide-driven cannot be verified from the transcript alone; the enumeration is audible but slide correspondence is unconfirmed. # Observation Record: Designing CLIs for Agents, Not Humans **Speaker:** Pedro Lopez, identified in the video metadata as from Airbyte. In the transcript he introduces himself as "Pedro," a software engineer at Airbyte. **Source:** Single-speaker conference talk transcript. All claims below are attributed to the speaker unless noted. **Scope:** Positions on Airbyte's MCP server and CLI, design lessons, and MCP-versus-CLI tradeoffs. --- ## 1. Company and Product Context - **Origin:** Airbyte began as an open-source standard for data movement, connecting SaaS tools (examples given: Zendesk, Stripe, GitHub) to data analytics pipelines. - **Current positioning:** The speaker says Airbyte has evolved into "the data and action layer for your AI agents." - **Context Store:** Described as a product that connects to the source tools and sits between agents and data, providing "a search optimized index" for efficient agent queries. - **Stated goal:** To "make data available and actionable everywhere." ### Access Interfaces | Interface | Stated Purpose | |---|---| | **SDK** | Building custom agents and tools | | **UI** | Quick use through the web app | | **MCP and CLI** | Making the Context Store available inside existing agents such as ChatGPT and Claude (the talk's focus) | --- ## 2. Capabilities Exposed The speaker names three capability areas that all interfaces should span: 1. **Resource management:** organizations, workspaces, and connectors. 2. **Authentication of third-party services:** described as needing to be "secure and doesn't expose your credentials to the AI agents." 3. **Ask and act:** searching the Context Store, plus reading, writing, and acting on connected systems. --- ## 3. Architectural Position - **Thin interfaces:** The speaker states that the MCP and CLI are "thin unified interfaces into our platform, not reimplementations of the platform." - **Surface layer role:** Mostly presentational. A command is taken, the platform is called, and results are formatted. - **Source of truth:** **OpenAPI specs** are described as the source of truth for connecting to Airbyte's APIs. Many interface components are built on these specs. - **Rationale for spec-driven design:** The platform "changes like over 10 times a day," so the speaker says the interfaces must be kept current. --- ## 4. MCP Positions ### 4.1 Target Audience - MCPs are "really great for users that might not be technical." - The cited use case is users who "just want to plug their data straight into Chat GPT or Claude." - Distribution: a listing in the ChatGPT app store. An Anthropic application is described as **pending**, with the speaker joking about needing approval from "anybody from Anthropic." - Even outside marketplaces, the speaker says installation is "pretty trivial": the user supplies the hosted MCP URL. ### 4.2 Tool Count > "We decided to keep the tool count small." - For connector execution, only **two main tools** are exposed: 1. **Describe**, which returns the connector schema. 2. **Execute**, which reads, writes, and deletes records. - **Reasoning:** Airbyte connects to many connectors, each with different entities and actions. Exposing one tool per action was considered and rejected. - **Chosen approach:** "Progressive discovery" of connector capabilities, with the amount of context placed in tool descriptions kept limited. - **Stated benefit:** This "really helps with the performance of the MCP server." - **Basis:** Described as the result of "trial and error." ### 4.3 Authentication: OAuth - The speaker's position: OAuth is the practical path for MCP authentication. - **Qualification:** The speaker says "technically you can use other authentication mechanisms," but "you're really going to have a hard time" with bearer tokens or similar. - **Reason given:** The MCP spec is "really heavy on OAuth," and the main clients "are really leaning towards the OAuth as a better UX." - **Example:** Anthropic's custom connector registration offers no way to enter a bearer token, so it "defaults to OAuth." ### 4.4 Long-Lived Sessions - Users are said to "expect to have long lived sessions." - The analogy offered is a **mobile app**, not a web app: users should not have to think about authentication. - **Implication stated:** Offline, long-lived sessions must be stored separately from the web app and have their own lifecycle. ### 4.5 Elicitation > "Elicitation though is not the way." - **Requirement:** Users must connect tools and provide credentials safely. - **Airbyte's current approach:** A link opens a widget where the user selects entities to connect, then redirects to the third-party OAuth flow (example: HubSpot). - **Spec context:** - Form-mode elicitation was "for the longest time" the only mode. The speaker says it is "not applicable for sensitive data like credentials." - **URL-mode elicitation** has more recently appeared and is "very similar to what we're doing." - **Obstacle:** Client support varies. A Claude Desktop example showed the client stating it does not support URL-mode elicitation. - **Decision:** Airbyte "had to go back to doing our own thing" rather than using the spec for this. --- ## 5. CLI Positions ### 5.1 Target Audience and Framing - CLIs are described as "the more technical counterpart," seen as "more powerful in some ways." - The speaker says CLIs should be "designed with agents in mind," noting that features helpful to human users can be blockers for agents. ### 5.2 JSON In, JSON Out - **Input:** Humans prefer flags, but for complex query inputs, agents are "really good at working with JSON" and construct it "in a much more direct and less guessy way." - **Output:** JSON "makes it easy to deal with longer responses" and enables Unix piping, for example through `jq`, to select and trim output. ### 5.3 Consistency - Commands should follow a predictable **noun-then-verb** structure. Examples: `connectors list`, `connectors create`, `workspace list`. - **Reasoning:** Agents should know the right way to do things "without having to read a bunch of documentation." - **Diagnostic heuristic offered:** If agents repeatedly make the same mistake, "consider making that your contract." The speaker reads repeated errors as a sign that the CLI contract is "not quite as obvious as it should be." ### 5.4 Skills - **Skills ship with the CLI.** The speaker says skills are "a must" because otherwise an agent has no way to know the CLI exists. - **Discovery:** A skill description surfaces when a user asks about connectors, prompting the agent to invoke the CLI. - **Context management:** - Skills should not contain too much, to avoid bogging down context. - Skills can point to **reference files** in a skill directory that expand on individual commands. - This "leverages the progressive discovery ability" of agents. ### 5.5 Non-Interactive Design - The speaker states that OAuth was a challenge on the MCP side and is "interesting in other ways for CLIs." - **Core claim:** A human cannot be assumed to be present to answer prompts. - **Requirement:** Inputs must come through **flags**, or for credentials, **environment variables and config files**, so setup happens out of band. - **Criticism of conventional CLIs:** Many human-oriented CLIs wait for interactive prompts, which causes agents to "just kind of get stuck there." --- ## 6. MCP vs. CLI Tradeoffs The speaker concludes that "both have their place." The tradeoffs are as follows. ### MCP Limitations - The spec is "not uniformly implemented across the board." - Providers add limits beyond the spec. Example: the speaker says Claude has a **2 kilobyte limit** on server and tool call descriptions. - Tool runtime is limited, making long-running processes harder. ### MCP Strengths - A **hosted server** can be always updated. ### CLI Limitations - **Versioning** is harder. Keeping packages current with new features is more difficult. ### CLI Strengths and Risks - No inherent limits, which allows longer-running tasks and long outputs. - **Risk stated:** The absence of limits "can make things go wrong and continually go through loops that make the agent spin." ### Recommended Use - **MCP:** Non-technical users, quick prototyping, one-off reports, and leveraging the MCP ecosystem for tools to talk to each other. - **CLI:** Technical users, longer-running tasks, and very long outputs. The speaker cites Unix features such as redirecting output to files, `tail`, and `head`. --- ## 7. Tensions and Qualifications These points are presented in the source without full resolution: - **Spec versus practice:** The speaker repeatedly notes that the MCP spec includes features (URL-mode elicitation, non-OAuth auth) that clients do not uniformly support, forcing custom implementations. - **OAuth as default versus alternatives:** OAuth is presented as the practical default, but the speaker acknowledges "technically" other mechanisms exist. - **Limits as both problem and protection:** MCP limits constrain functionality, while the lack of CLI limits creates risk of agent loops. The speaker does not state a resolution to this tradeoff. - **Human-friendly versus agent-friendly:** Several conventional CLI features (flags for complex input, interactive prompts) are described as suitable for humans but problematic for agents, though flags are still recommended for simple configuration. - **Versioning:** The MCP's always-current hosted advantage is contrasted with the CLI's versioning burden. No mitigation is described. --- ## 8. Demonstrations (as Described) - **MCP example:** A user asked which connectors were available. The MCP reported four connectors in the workspace. The user then asked for "five paying customers with Zendesk support tickets." The MCP searched the Context Store, combined Zendesk and Stripe data, and returned five customers with open support tickets. - **CLI example:** The same questions were asked. The agent loaded a skill describing the CLI, used the CLI to query and aggregate Context Store data, and returned the same five users. - **Note:** These are the speaker's descriptions of live demos. No independent verification is provided. --- ## 9. Not Stated in the Transcript - No quantitative performance measurements are given for the two-tool design or for JSON versus flags. - The outcome of the Anthropic marketplace application is not reported. - No specific mitigation is described for CLI agent loops or CLI versioning. - The "10 times a day" deployment figure is stated without supporting data. - The reference to the Claude 2 KB limit is the speaker's claim; the transcript provides no source for it. # Speaker and Provenance Observation: "Designing CLIs for Agents, Not Humans" ## Video Identification - **Video ID:** 01a15ca6-dc3f-7c0c-8df0-318b949f064b - **Title:** Designing CLIs for Agents, Not Humans, Pedro Lopez, Airbyte - **Curated metadata supplied:** Title only. No speaker roster, cited-source list, sponsorship disclosure, or comment-availability data was provided. ## Speakers and Roles ### Speaker 1: Pedro Lopez - **Role:** Presenter and speaker throughout the entire transcript - **Stated affiliation:** Self-described as "a software engineer at Airbet," which the title identifies as Airbyte. The transcript spelling is likely a transcription variance. - **Identity basis:** Self-introduction in the transcript ("my name is Pedro") and the title. The surname appears only in the title. - **Speaking scope:** Presents on the company's MCP server and CLI, offering product context, demonstrations, design guidance, and tradeoff discussion. - **Other speakers:** None identified. No questions, audience responses, or guest contributions appear in the transcript. ### Organizational Context Stated by the Speaker - **Employer:** Airbyte, described as a company that began as "the open-source standard for data movement" and now positions itself as "the data and action layer for your AI agents." - **Product interfaces named:** SDK, web UI, MCP, and CLI. ## Promotional Segments The following segments are promotional in nature and should be weighed as such by later authors: - **Company introduction (opening):** Describes Airbyte's history and its "context store" product, and states the goal to "make data available and actionable everywhere." - **Marketplace listing reference:** Points to Airbyte's listing in the ChatGPT app store and notes a pending Anthropic application. - **Closing call to action:** Invites attendees to "check out" the Airbyte booth and "come work with us." ## Referenced Sources and Named Third Parties - **Third-party SaaS tools named as connectable:** Zendesk, Stripe, GitHub, HubSpot - **AI platforms named:** ChatGPT, Claude (including Claude Desktop), Anthropic (as a registration and approval channel) - **Technical standards and tools referenced:** MCP specification, OpenAPI specs (described by the speaker as the source of truth for API connection), OAuth, bearer tokens, jq, Unix pipes - **Demonstration outputs:** Two live demos are described. In each, the speaker reports results from querying a workspace with four connectors, including a list of five paying customers with Zendesk support tickets. These are speaker-reported demo outputs. No independent verification is present. ## Third-Party Claims Made by the Speaker These are assertions about external systems, presented without citation in the transcript: - Claude imposes a **2 kilobyte limit** on server and tool call descriptions. - Claude imposes a **limit on how long tools can run**. - MCP clients vary in support for spec features. A Claude Desktop message is cited as evidence that it does not support URL mode elicitation. - The MCP spec is "really heavy on OAuth," and major clients favor OAuth over bearer tokens for installation. - Airbyte's platform changes "over 10 times a day" (a self-reported internal claim). ## Provenance Limits and Unavailable Channels - **Visual materials:** The transcript refers to a ChatGPT listing, an Anthropic custom connector registration screen, a Claude Desktop error message, and live demo screens. These visuals are not available in the transcript and cannot be checked from it. - **Comment availability:** Not supplied. - **Cited external documents:** None are given as links or citations. The MCP spec, the Claude limits, and the OpenAPI references are named but not linked. - **Demo reproducibility:** Demo results depend on live connector data that is not included. ## Self-Check - Speaker identity and role are explicit in the transcript and title. - Promotional segments are flagged in a dedicated section. - Third-party claims are separated from the speaker's own statements and marked as uncited. - No quality judgments are recorded. Hello everybody. Uh my name is Pedro. I'm a software engineer at Airbet. And today we're going to be talking about how we built our agent MCP and our CLI. Um, and before we go into the nitty-gritty of all of that, um, I wanted to give a bit of context on what we do at Airbet and how all of this kind of fits into, uh, our product. So, Airbite's been around for a while. Um, we started as the open- source uh, standard for data movement. Um, connecting all of your SAS tools that you might be using like Zenesk, Stripe, uh, GitHub, etc. to um, your data analytics pipelines. And now we're using that same expertise and have evolved to being the data and action layer for your AI agents. Um, and we do that by offering a or agent product um that has what we call the context store which connects to all of those tools that that I mentioned before and sits in between your agents um to provide a search optimized index of all of your data um that is able to be more efficiently queried by your agents. So, you're able to gather information about all of these um records and and and contacts and stuff that you might have in these all all these tools and join them together in an easy way uh through our contact store. And so, our goal is that we want to make data available and actionable everywhere. And so, we have a couple different interfaces by which you can access this context store. Um, one is our SDK, which is more usable if you are uh building your own agents and your tools. Um, our UI, which is, um, just a quick way that you can use it through our web app. Uh, and then what we're going to be focusing on in this talk, which is our MCP and our CLI, which is um, a way to easily make that um, available within existing uh, agents like Chad GBT um, and and Claude. So what exactly are we exposing through these interfaces? Um three main things. One is the ability to manage all of the the core resources of our product to our organizations workspaces and connectors. Um and so all these interfaces should let you uh interact with that. Second um super important is be able to authenticate those thirdparty services that I mentioned about earlier um and do so in a way that's secure and doesn't expose your credentials uh to to the AI agents. And third um ask and act. So we want to expose the ability to search across the context store uh be able to read and write uh take action on all those systems. Um, and so we want all of our interfaces to be able to span across these uh three capabilities. Um, so the MCP and the CLI, the way the way that we've structured things is that they are thin unified interfaces into our platform, not reimplementations of the platform. So most of the surface layer of these uh interfaces are presentational where you take a command uh and you call the platform and format the results in some way. Uh and everything kind of sits on top of our shared platform and APIs. Um and because we want to we deploy a lot, you know, our our platform changes like over 10 times a day, we want to keep these things up to date as we go. And so a big part of this as well is open a open API uh specs as a source of truth for how to connect to to our APIs. And a lot of those interfaces um are built on top of uh those specs. Okay, so let's go into these interfaces. Let's start with let's start with the the MCP. And so MCPs are really great for users that might not be technical. Um, and in our case, it's great for those users that just want to plug their data straight into Chat DBT or Claude in an easy way. Um, and the cool thing is they're they're very nicely packaged. They're very uh easy to install. For example, here's our um listing on the Chad GBT app. uh listing the official uh store that they have. Um and we also have a application for the the anthropic one uh which we're still pending on if there's anybody from Enthropic out there that wants to approve us. Um but even if you're not on these marketplaces, um they are pretty trivial to install uh for a an end user. You just give it the hosted MCP URL and you're able to um connect pretty quickly. Okay, so let's look at uh an example. This is our MCP in action. Here I'm asking, you know, which connectors do I have available? Um, and it goes through, hey, I have four connectors set up in this workspace. And then I can ask it some questions about my data like show five paying customers with Zenes support tickets. Um, and so this right now is looking through all the connectors that we have, searching the context store for that information that I that I asked it about. Um, and then combining that information across Zenesk and Stripe, um, so that it can come up with an answer for me. Okay. And there we go. So it cross referenced Zenesk and Stripe and then came back with, you know, five of those people that um, have open support tickets. Cool. So let's go into kind of some lessons learned while building this uh MCP and things that you might want to keep in mind if you're doing uh something similar. So one thing that we decided to do um after trial and error is to keep the tool count small. So um we for the execution part of the connector where you're pulling that data, we only expose or really deal with two main tools. one is to describe the connector to get the schema of how do you query that information and two is the execute that's able to read write and delete records. Um the opposite end of the spectrum here would be since we connect to so many different um connectors and each of these has different entities different actions you can take. We could have exposed, you know, an MCP tool for each one of these. Um, but instead what we found is really keeping it narrow, using progressive discovery of all of the capabilities um that the connector has available. Um, and really limiting the amount of context that you shove into the those tool descriptions um really helps with the the performance of the of the MCP server. Two, Olaf is the way. So this this refers to how you authenticate the MCP server itself. Um so this is an example for like anthropic. You click a button uh to connect and that spins up our ooth flow. So you can sign in to air bite um accept the the privileges and then you're all set up with all the connectors that you've uh linked up. Um, and technically you can use other authentication mechanisms through MCP, but you're really going to have a hard time um if you do like beer off or or anything like that because the spec is really heavy on ooth and all of the clients, the the main ones at least um are really leaning towards the the OAF as a better UX for uh installing that connector. So that's an example for uh the the enthropic um custom connector um registration where they have no no way of you to put like a bearer token or anything. It's just all defaulting to to OOTH. So that's is is very important. And two, users actually expect um to have long lived sessions uh through these MCP servers. Um unlike a web app where you might be okay with having to sign in again um a couple times, uh users expect to use MCPs more like a mobile app where they don't really have to think about authenticating. It's just available uh whenever they want to use it. And so that has its own little um you know uh things to keep in mind as you're implementing ooth is keeping offline long sessions um that are stored separately from the web app and have its own set of uh of life cycles. Cool. Elicitation though is not the way. So I'll get into what elicitation is but a big part of um the MCP server that I mentioned is you need to be able to connect your tools. you need to be able to give credentials in a way that's safe. Um, and to do that, uh, basically when you ask, you know, how do I connect to to HubSpot? Um, we generate a link that you go to which you can pops up this widget and you're able to select, you know, which uh entities you want to connect and redirect to to HubSpot to go through the that OOTH flow. Um, now technically MCP has something in the spec that allows you to surface those kinds of URLs um and and process those inputs um called elicitation. It's a way that you can request information from the user. For the longest time um it was only form mode elicitation which is not um applicable for sensitive um sensitive uh data like credentials for an API. But more recently um this URL mode elicitation became a thing um that is very similar to what we're doing. But the problem is uh support across the MCP clients. So that's a big theme uh when working with MCP is that even though there is a spec features that is are supported across the clients kind of vary quite a bit. Um so this is an example from cloud desktop where you know it just is telling me hey I don't support URL mode elicitation. I can't do that. And so we had to go back to doing our own thing um and not using the spec for that for that kind of thing. Okay, let's talk about the CLI a bit. So if MCPS are easy for these non-technical users, um CLI are kind of the more technical counterpart might call it the kind of more powerful in some ways that we'll get into. And this is the the same example we saw earlier, but this time with the the MCP or sorry, with the CLI where we're asking, you know, which connectors do I have available? It's this time loading a skill that tells it about the CLI. Um, and then, you know, using the CLI itself to query things. We got back the connectors. Then we asked, you know, show five paying customers that have Zenes support tickets. Same as last time. um it's able to this time use the CLI to query that query the context store aggregate that data and then eventually it should come back with a result now okay um so there's those same five um five users so um on the design side for CLI I think one important thing to keep in mind is to design those CLIs with agents in mind um some of the things that might be helpful for users when you're making a CLI are going to be like blockers for agents. Um, and we'll get into that a little bit more. Um, the first design decision here that we made was take JSON in and return JSON out. So uh for humans it's very nice to specify um a bunch of flags uh to work with CLIs but when it comes to these more complicated um inputs that uh you have to build to to make these queries and agents are really good at working with JSON. um they're able to construct this uh in a much more um direct and and less of a guessy way um than using those flags. And so on the output, JSON also makes it easy to deal with longer responses um be able to leverage one of the key capabilities of CLIs, which is hey, you have these this Unix system with pipes that you can redirect the output to different um programs. So you can use jq for example to select certain certain things from the output and trim that and so JSON really unlocks a lot of that um capability. Two consistency is very much key here. So it should be dead obvious for agents to know how to do something across all of the resources that you're exposing. If you have structured your CLI in a way that it's it's structured where there's a noun and then a verb for this example you know connectors list connectors create make sure that when you're implementing a workspace um CLI uh commands they also follow that same format. So workspace list is another one that that we have. And so it's very um critical that agents know the right way to do things and it's easy for them to know the right way to do things without having to read a bunch of documentation. And another interesting fact here is, you know, if you see agents making the same mistake over and over, um calling the wrong command a bunch of times, consider making that your contract. Make it dead simple for agents to stumble across the the right way to to use things. um because that usually means that something is not quite as obvious as it should be in your AP in your CLI contract if agents keep making the same kind of mistakes. Three, skills are skills ship with uh the CLI tool. So skills are a must uh when you're doing CLIs because how else if you have a CLI installed is an agent going to know that that CLI even exists in the first place. So it helps a lot with discovery of uh your tools that are available. Um and they also help with uh using that tool effectively. So uh we have a skill that gets surfaced. It has a a description that is able to come up whenever you ask anything about connectors. It knows to bring up that CLI and invoke it. Um and then the way that you structure the skill is also something to um think through. you know, you don't want to put too much into the skill uh that you're going to bog down the context. Um, skills have this uh ability to be separated out into references um where you can have a main skill that points to other files in a in a skill directory um that can expand information about the the different commands. And that really uh helps cut down the the amount of uh of context that you're loading in and um leverages the progressive discovery um ability of uh of these agents. Cool. And then another interesting fact uh for off side, off was interesting on the MCP side. It is interesting in other ways for CLIs because we can't assume that a human is going to be present to able to interact with those prompts. Um when CLIs are being invoked by agents, it can't sit there and wait for you to type um a prompt into the CLI. you have to expose things either through flags um or in the case of credentials environment variables and config files um so that things can be set up out of band and you don't have to wait for that uh whenever you're invoking the CLI um and I would say aside from off um that's a general thing a lot of CLIs that are built for humans you type a command and it'll wait there ask you for prompts uh and that is not um you know able to be used properly ly by these agents. Um they'll just kind of get get stuck there. Um cool. So CLI and MCPs, which one is better? Well, they both have kind of their own trade-offs. You know, with the MCP, the spec is not uniformly implemented across the board. Um there's a bunch of limits that these providers decide to implement aside from the spec as well. For example, like Claude has a 2 kilobyte limit on server and tool call uh descriptions. There's a limit of how long the tools can run. So it's harder to do more longunning processes through MCP. Um and uh you know there's there's other kind of kind of limits that they've introduced there. And then on the CLI, the cool things about MCP like you know you can have a hosted MCP server that just is always updated. That's not quite the case with the CLI. you have to think more about versioning. It's harder to keep packages up to date uh with all these new features. Um and there's no while the limits can be well limiting on the MCP side, not having any of those on the CLI across the tools uh across the the calls of the CLI can make things go wrong and continually go through loops that um you know make the agent spin. And so really I think both have their place. I think MCPs are great for those non-technical users, be able to quickly prototype things, build one-off reports, um, and even leverage that MCP ecosystem to have things uh, talk to each other. And then the CLI is better for those more technical users, more longer running tasks, maybe outputs that are super long and you need to leverage those um features that Unix and and the pipes give you where you can redirect output to a file. You can do a tail, do a head on that output. Um that's where really the the CLI um starts to to shine. All right, that is basically all that I had. Um, we have a booth over there at Airbite um that you should check out and come work with us. Thanks.