Dated Bubble, Lovable, Base44 and Replit findings on code export, GitHub, backends and databases.
Scored across 3 tools
Each tool has a distinct role: search_findings discovers record IDs, get_finding retrieves one exact record, and compare_products produces a multi-question comparison. The descriptions explicitly explain the search-vs-retrieve relationship and the boundary of compare_products, leaving no meaningful overlap.
All three tools follow a clean verb_noun pattern (search_findings, get_finding, compare_products) in consistent snake_case. The convention is predictable and readable throughout.
Three tools is a slightly thin but defensible surface for a narrow, evidence-lookup server focused on find/retrieve/compare. It earns its place but leans toward minimal, with no tool for browsing coverage or listing products directly.
The set covers the core lifecycle of discovery (search), retrieval (get), and synthesis (compare) for dated findings, which is coherent. There is a minor gap: descriptions reference 'coverage' capability IDs that have no dedicated tool to enumerate, forcing reliance on search.
Compare 2–4 covered app builders on the released code, GitHub, backend and database questions. Specify capability IDs from coverage or search results, or omit them for all four questions. Preserves separate dates and unknowns; provides no overall ranking.
| Name | Required | Description | Default |
|---|---|---|---|
| products | Yes | Two to four distinct covered product names or IDs. | |
| capability_ids | No | Exact capability IDs from coverage or search results. Omit to compare all four covered questions. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| error | No | |
| dataset | No | |
| coverage | Yes | |
| products | No | |
| limitations | No | |
| capabilities | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so safety behavior is covered. The description adds genuine non-obvious behavior: it preserves separate dates and unknowns and deliberately provides no overall ranking, which sets the agent's expectation for the result shape.
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 tight sentences, front-loaded with the verb and cardinality constraint, then parameter guidance, then output caveat. No filler.
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 format needn't be spelled out, and the description still adds the key expectation-setting facts (no ranking, preserved dates/unknowns). Complete enough to invoke correctly, with only minor omissions like result limits or latency.
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?
Schema coverage is 100% so the baseline is 3, but the description exceeds it by naming the four questions (released code, GitHub, backend, database) that capability_ids select among, a detail the schema does not enumerate.
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 (compare) plus resource (covered app builders) and enumerates the four question areas, so the agent knows exactly what the tool produces and how it differs from the single-result get_finding and search_findings 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?
Gives clear operational guidance: specify capability IDs 'from coverage or search results, or omit them for all four questions', which routes the agent to the search flow and tells it omitting is valid. It does not explicitly state when not to use it versus the sibling tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve one exact finding using a record ID returned by search_findings or compare_products. Returns the published answer, scope, original dates, conditions, limits, source links and dataset attribution.
| Name | Required | Description | Default |
|---|---|---|---|
| record_id | Yes | Exact record_id from a prior result. Do not invent an ID. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| error | No | |
| dataset | No | |
| finding | No | |
| coverage | Yes | |
| limitations | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds genuine behavioral context beyond that: the retrieval is exact-match on a record ID (no fuzzy lookup) and the answer is the 'published' variant, which implies unpublished or draft findings are not reachable this way.
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?
Two tight sentences: the first covers the action, input and source; the second covers the payload. Zero filler and the core purpose is front-loaded.
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 the return-value list is not strictly necessary, and the annotations plus single documented parameter leave little an agent must infer. The only unfilled gap is failure behavior for a stale or malformed record ID, which is minor for a read-only exact lookup.
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?
With one parameter at 100% schema coverage, the schema already documents the record_id pattern and the 'Do not invent an ID' warning. The description reinforces provenance ('returned by search_findings or compare_products') but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.
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 (Retrieve) and resource (one exact finding) with an explicit scope qualifier ('one exact'). It also names the two sibling tools that produce the required ID, so an agent can place it relative to search_findings and compare_products 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'using a record ID returned by search_findings or compare_products' establishes the prerequisite and the correct upstream workflow, which is exactly the guidance an agent needs. It stops short of stating what to do when no ID exists or when to prefer a fresh search, so it is clear context rather than a full when/when-not rule set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find dated findings about code export, GitHub sync, backend connections and databases for Bubble, Lovable, Base44 and Replit. Use this to discover record IDs; get_finding retrieves one exact record. Other topics return no matches, not a product verdict.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum findings to return, from 1 to 16. Default: 16. | |
| query | Yes | A product question or covered topic, such as “Can Bubble and Lovable export source code?” | |
| products | No | Covered product names or IDs. Use the coverage resource to see available products. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| error | No | |
| query | No | |
| dataset | No | |
| coverage | Yes | |
| findings | No | |
| truncated | No | |
| no_matches | No | |
| limitations | No | |
| matched_count | No | |
| returned_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description only needs to add context beyond that. It does add useful behavior: uncovered topics yield empty results rather than an error or judgment, and results are 'dated'. It stops short of describing ranking or pagination behavior, but the output schema covers return shape.
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 short sentences, front-loaded with the scope, then the routing rule, then the negative-result caveat. No sentence is redundant and nothing is buried.
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?
With an output schema present, return values need not be explained; annotations carry the safety profile; and schema coverage is complete. The description supplies the domain scope, the sibling routing rule, and the empty-result expectation, leaving no material gap for correct invocation.
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?
Schema coverage is 100%, so the baseline is 3. The description earns above baseline by enumerating the concrete covered topics and the four supported products, which concretizes what valid `query` and `products` values look like beyond the schema's generic phrasing ('covered topic', 'covered product names or IDs').
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 gives a specific verb ('Find') plus resource ('dated findings'), and scopes it to concrete topics (code export, GitHub sync, backend connections, databases) and named products (Bubble, Lovable, Base44, Replit). It explicitly distinguishes itself from the sibling get_finding, so an agent can route correctly 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the use case ('discover record IDs') and names the alternative with its differentiating condition ('get_finding retrieves one exact record'). It also bounds applicability by warning that other topics return no matches, which tells the agent when not to rely on this tool.
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.
compare_productsget_findingsearch_findingsManaged database, auth, file storage, email, analytics, and deployment for coding agents.
Backend for vibe coders. Connect Butterbase to any MCP-compatible AI coding tool and provision a full backend automatically — database, authentication, file storage, edge functions, and real-time — from a natural language prompt. No SQL, no configuration, no backend knowledge required. Free to start at butterbase.ai.
Build, version, review, and export websites, web apps, and games from a conversation.
Production backend for AI-built apps: storage, data, jobs, webhooks, email, metering and billing.
Add one secure layer between your agents and this server.
