Provides knowledge and tools for building on Cloudflare's developer stack (D1, R2, KV, Auth) and allows managing Cloudflare projects, D1 databases, and R2 buckets via the Flarelink dashboard API.
An MCP server that teaches your AI coding tool to build correctly on the Flarelink stack — Cloudflare auth (better-auth + KV sessions), D1, and R2 — from inside Cursor, Claude Code, Windsurf, and anything else that speaks MCP.
It hands the agent the security and cost rules up front (user-scoping, identifier-safe SQL, KV sessions, presigned R2) so the generated code is right the first time, instead of the agent guessing and you debugging.
No install needed — run it with npx. Add it to your tool's MCP config:
Claude Code
claude mcp add flarelink -- npx -y @flarelink/mcpCursor / Windsurf / Claude Desktop (mcp.json / config):
{
"mcpServers": {
"flarelink": {
"command": "npx",
"args": ["-y", "@flarelink/mcp"],
"env": { "FLARELINK_API_KEY": "flk_…" }
}
}
}The FLARELINK_API_KEY is optional. Without it you still get all the
knowledge + scaffolding tools. With it, the management tools (below) can
drive your actual Flarelink projects. Mint a key at
dash.flarelink.dev → API keys.
Related MCP server: Cloudflare MCP Server
Tool | What it gives the agent |
| The stack, cardinal rules, and deployment shapes. Read first. |
| How to bootstrap a complete working app (clone / one-click deploy) + file map. |
| The catalog of canonical code patterns. |
| Copy-pasteable code for one recipe (auth setup, route guards, identifier-safe D1, R2 upload/presign, wrangler bindings, SDK usage). |
|
|
| Cloudflare cost-optimization guidance, with targeted hints for the feature you describe. |
It also exposes the stack guide as a resource (flarelink://stack-guide) you can attach as context.
FLARELINK_API_KEY)Drive your actual Flarelink projects from the editor. These route through the Flarelink dashboard API and act exactly as you would in the UI.
Tool | What it does |
| Verify the key; show the user + active connection/project. |
| List projects on the active Cloudflare connection. |
| List the project's D1 databases. |
| Run a (parameterized) SQL statement against a project D1. |
| List the project's R2 buckets. |
Without a key they return a clear "set FLARELINK_API_KEY" message. The key has the same access as your Flarelink login — treat it like a password.
MIT. Part of Flarelink — the dashboard for the Cloudflare developer stack.
Design guidance (not a live usage meter) for keeping a Cloudflare bill near zero. Optionally describe the feature you are building to get targeted hints first.
| Name | Required | Description | Default |
|---|---|---|---|
| feature | No | Optional: describe the feature/data shape (e.g. "user avatar uploads") for targeted hints. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure. It effectively explains that the tool provides design guidance rather than live data, and that supplying a feature description may yield targeted hints. This is helpful, but it stops short of describing the exact return format or behavior when no feature is given, leaving some ambiguity.
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, well-structured sentence that front-loads the core purpose, followed by a brief note on the optional parameter. Every word earns its place, with no redundancy or 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?
For a tool with one optional parameter and no output schema, the description covers the main purpose, the non-meter caveat, and the optional targeted hints. It does not describe the output structure, but given the simplicity of the tool, the description is sufficiently complete for an agent to invoke it 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?
The schema already documents the optional feature parameter, so the baseline is 3. The description adds value by explaining the purpose of the parameter ('to get targeted hints first'), which goes beyond the schema's minimal description and helps an agent decide whether to provide it.
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 this is design guidance for keeping a Cloudflare bill near zero, with an explicit scope and a disclaimer that it is not a live usage meter. It distinguishes itself from siblings by focusing on cost-optimization patterns rather than generic pattern listing or retrieval, though sibling tools are not explicitly named.
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 gives clear context: use this when designing for Cloudflare cost optimization, and optionally describe the feature for targeted hints. It explicitly excludes real-time usage metering, providing a 'when-not-to-use' signal, though it does not mention alternatives like flarelink_list_patterns or flarelink_get_pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the canonical, copy-pasteable code for one Flarelink-stack recipe (auth setup, route guards, identifier-safe D1 queries, R2 uploads/presigning, wrangler bindings, SDK usage). Prefer these over inventing your own — they encode the security + cost rules.
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | Which pattern to fetch. Use flarelink_list_patterns to see the options. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It adds meaningful context about the canonical, security/cost-encoded nature of the returned code, implying a safe read operation, though it does not explicitly discuss error handling or confirm read-only behavior.
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 sentences, front-loaded with the primary purpose, no wasted words. Every sentence contributes to purpose or 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?
For a simple one-parameter tool with an exhaustive enum and existing schema description, the description fully addresses what the tool does and how to use it. The lack of an output schema is compensated by the clear statement that it returns copy-pasteable code.
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 schema already provides full coverage with an enum and description. The description's parenthetical list of recipe types (auth setup, route guards, etc.) adds semantic meaning beyond the schema by giving concrete examples of what the pattern values represent.
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 'Return[s] the canonical, copy-pasteable code for one Flarelink-stack recipe' with a specific list of recipe types, effectively distinguishing it from sibling tools like flarelink_list_patterns which lists options.
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?
Explicit guidance: 'Prefer these over inventing your own' tells when to use this tool instead of writing custom code, and the schema directs to use flarelink_list_patterns for discovering options, covering both when and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the R2 buckets attached to the active Flarelink project.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. 'List' clearly indicates a read-only operation, but the description does not mention return format, whether the operation requires special permissions, or what 'attached' means. For a simple list operation, this provides baseline transparency but not additional 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 a single, front-loaded sentence with no redundancy. Every word contributes meaning.
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 this is a zero-parameter, no-output-schema list operation, the description fully covers what the tool does. The sibling tool names provide additional context, and the description mentions the active project scope. There is no missing essential information.
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 tool has zero parameters, so the description cannot add parameter-level detail. The baseline for 0-param tools is 4, and the description does not need to compensate. It correctly mentions the only relevant context (active project).
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 'List the R2 buckets attached to the active Flarelink project,' which specifies the verb (List), the resource (R2 buckets), and the scope (active Flarelink project). This distinguishes it from sibling tools like flarelink_list_databases and flarelink_list_projects.
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 does not explicitly state when to use this tool versus alternatives, but the context of 'active Flarelink project' implies it is for the currently selected project. It does not provide exclusions or alternative tool references. Since the tool name already clarifies its purpose, this is minimally acceptable but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the D1 databases attached to the active Flarelink project (id, name, whether it hosts the auth module).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly implies a read-only list operation and specifies the return fields (id, name, auth module flag), but it does not disclose potential errors, authentication needs, or behavior when no active project exists. This is adequate but not detailed.
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 sentence, front-loaded with the verb 'List', and contains no wasted words. It is concise and directly informative.
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's low complexity (no parameters, no output schema) and the presence of sibling tools, the description provides enough information to invoke the tool correctly. It specifies what is returned, but a bit more detail on the exact response structure or edge cases would make it more complete. Still, it is adequate for a simple list operation.
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 tool has zero parameters, so the schema already covers all possible inputs. The description adds context about the output scope (active project) and the fields returned, which is useful beyond the empty 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 the tool lists D1 databases attached to the active Flarelink project, specifying the resource and scope. It distinguishes itself from sibling tools like list_projects and list_buckets by naming the exact resource type.
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 context that it operates on the active project, but it does not explicitly contrast with alternatives such as list_projects or query_database. Usage is implied rather than clearly stated with when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the available canonical code patterns (keys + what each is for). Use flarelink_get_pattern to fetch one.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It indicates the list contents ('keys + what each is for') but does not explicitly state that it is a read-only operation or describe return format/pagination. This is a minor gap for a simple list tool.
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 extremely concise, with two sentences: the first states the primary purpose, the second directs to the sibling tool. Every word earns its place, and it is front-loaded with the core function.
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?
For a zero-parameter list tool, the description is nearly complete. It explains what the list contains and points to the appropriate sibling for single-item retrieval. The lack of an output schema is partially mitigated by the description mentioning keys and purposes, but it does not detail ordering or error cases.
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, so the baseline for parameter semantics is 4. The description adds context about what is listed (keys and purposes), which is relevant even though there are no parameters to document.
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 lists available canonical code patterns with keys and purpose, using a specific verb + resource. It distinguishes itself from the sibling tool flarelink_get_pattern by noting that fetching a single pattern is done via that tool.
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 an explicit alternative: 'Use flarelink_get_pattern to fetch one.' This gives clear guidance for when to use this tool versus a key sibling. It does not explicitly exclude other siblings, but the main alternative is addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the Flarelink projects on the active Cloudflare connection.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'List' implies a read-only operation, but it does not disclose behaviors such as error handling when no active connection exists or the return format. The scope is clear, but some transparency gaps remain.
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, direct sentence that states the action, resource, and context without any redundant or irrelevant 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?
For a simple zero-parameter list tool, the description adequately explains what it does and in what context. However, it does not specify the return format or edge-case behavior, which could be expected without an output schema.
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 properties, so the baseline for parameter semantics is 4. The description does not need to explain parameters, and it does not introduce any parameter-related confusion.
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 verb 'List' and the resource 'Flarelink projects' with the context 'active Cloudflare connection'. This distinguishes it from sibling tools like flarelink_list_databases and flarelink_list_buckets.
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 gives clear context (active Cloudflare connection) implying when it is applicable, but does not explicitly mention alternatives or when not to use it. The tool is self-explanatory for its purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a SQL statement against one of the project's D1 databases via Flarelink. Use bound parameters (? placeholders + params) — never concatenate user input. Returns rows + query meta (duration, rows_read/written). This runs with full database access; prefer SELECT unless you intend to write.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SQL with ? placeholders for any values. | |
| params | No | Values bound to the ? placeholders, in order. | |
| databaseId | Yes | D1 database id (uuid) — from flarelink_list_databases. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states 'runs with full database access' and returns 'rows + query meta (duration, rows_read/written),' disclosing the write risk and output behavior. The warning to prefer SELECT adds important safety 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?
Three sentences, front-loaded with the core action, then security guidance, return format, and a safety warning. Every sentence adds necessary information with no fluff or repetition.
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?
Despite no output schema, the description explains the return value (rows + meta). For a 3-parameter tool with high schema coverage, it covers purpose, usage, parameter binding, safety, and output — sufficiently complete for an agent to select and invoke the tool 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?
Schema coverage is 100%, but the description adds meaningful context beyond the schema by explaining the relationship between sql and params: 'Use bound parameters (? placeholders + params) — never concatenate user input.' This clarifies how to construct the sql string and use params safely, surpassing the schema's basic descriptions.
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 verb ('Run') and resource ('SQL statement against one of the project's D1 databases'), making the tool's purpose unambiguous. It distinguishes itself from sibling tools that list databases or patterns, as this is the query execution tool.
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?
Provides clear guidance on how to use the tool safely: 'Use bound parameters (? placeholders + params) — never concatenate user input' and 'prefer SELECT unless you intend to write.' This implies when to use (reads) and cautions against unintended writes, though it does not directly name alternative tools for non-query operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How to bootstrap a complete, working Flarelink-stack app (auth + D1 + R2): clone command, one-click deploy, file map, and where to add features.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It explains that the tool provides a guide covering clone, deploy, file map, and feature addition, but does not specify whether the tool actually executes commands or simply outputs instructions, leaving a minor ambiguity. It adds context about scope (auth + D1 + R2) beyond the title.
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, well-formed sentence that front-loads the purpose and uses a colon to enumerate specific content categories. There is no wasted text.
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?
For a no-parameter informational tool, the description covers the essential aspects: what the guide includes and the stack components. It does not mention prerequisites or the format of the output, but given the absence of output schema and simple nature, it is reasonably complete.
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 tool has zero parameters, so baseline is 4. The description adds no parameter-specific meaning, but none is needed.
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's function: bootstrapping a complete Flarelink-stack app with auth, D1, and R2. It lists concrete deliverables (clone command, one-click deploy, file map, feature locations) that distinguish it from sibling tools like flarelink_stack_overview.
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 implies the tool is used when you want to scaffold a new Flarelink-stack app, providing practical bootstrapping steps. However, it does not explicitly mention when not to use it or recommend an alternative sibling tool, so the guidance is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Signatures and return shapes for the @flarelink/client SDK (auth / storage / db). Use when the app talks to a hosted Flarelink auth Worker rather than embedding better-auth.
| Name | Required | Description | Default |
|---|---|---|---|
| surface | No | Which surface to return. Defaults to all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of disclosure. It clearly indicates the tool is a reference (returning signatures and shapes) and adds context about the intended deployment scenario, implying it is non-destructive. It does not explicitly state safety or return format details, but for a reference-like tool the behavior is adequately transparent.
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 two short, well-structured sentences. The first sentence delivers the core purpose, and the second provides usage context. Every word earns its place, with no redundancy or 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?
This is a simple single-parameter reference tool with no output schema. The description covers what it returns, which surfaces it applies to, and when to use it, which is sufficient for an agent to select and invoke it correctly. No critical gaps remain.
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 schema already fully describes the only parameter 'surface' with an enum and a default value ('Defaults to all'). The description echoes the surface names but does not add significant meaning beyond the schema, so the baseline 3 is appropriate.
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 provides 'Signatures and return shapes' for the @flarelink/client SDK, specifying the surfaces (auth/storage/db). This concise verb+resource structure distinguishes it from sibling tools like flarelink_get_pattern or flarelink_scaffold, which serve different purposes.
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?
Explicit guidance is given: 'Use when the app talks to a hosted Flarelink auth Worker rather than embedding better-auth.' This directly tells the agent when to select this tool over alternatives, satisfying the usage guideline dimension fully.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read this first. The Flarelink stack (Cloudflare auth via better-auth + KV sessions, D1, R2), its cardinal rules, and the two deployment shapes. Call before building auth/database/file features on Cloudflare.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adequately discloses the tool's behavior as a read-only informational overview. It states what content will be learned (stack components, rules, deployment shapes) without any side effects. It could explicitly state that it makes no changes, but the wording 'Read this first' strongly implies a safe query operation.
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 two sentences: the first front-loads the 'read this first' instruction and lists content; the second gives a clear usage directive. Every sentence earns its place without redundancy or fluff.
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?
For a simple overview tool with no parameters and no output schema, the description fully covers its purpose, content, and usage context. It tells the agent what to expect (stack details, rules, deployment shapes) and when to call it. No additional information is needed for correct selection and 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?
The tool has zero parameters, so the schema is fully self-sufficient. The description doesn't need to explain parameters, and baseline for 0 params is 4. No parameter-related information is required beyond what the schema shows.
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 identifies this as an introductory overview tool for the Flarelink stack, listing specific components (Cloudflare auth via better-auth + KV sessions, D1, R2) and topics (cardinal rules, deployment shapes). It distinguishes itself from sibling tools by being the 'read this first' entry point, though it doesn't explicitly contrast with 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?
The description gives an explicit when-to-use instruction: 'Call before building auth/database/file features on Cloudflare.' This is actionable and implies precedence over other tools, effectively guiding the agent to use this tool as a prerequisite. No alternatives are named, 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.
Verify the FLARELINK_API_KEY and show the signed-in user plus the active Cloudflare connection and project. Call this first to confirm management tools are wired up.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses verification and display actions, implying a read-only diagnostic, but does not explicitly state it has no side effects or describe error behavior if the API key is invalid. Adequate but with gaps.
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 concise sentences immediately state the action and usage guidance. Every word earns its place, with no filler or repetition.
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?
For a simple whoami tool with no parameters and no output schema, the description covers function and usage adequately. It lists what is shown (user, connection, project) and advises calling it first. Minor gap: no explicit output format, but return values are implied by the listed items.
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 tool has zero parameters, so schema coverage is trivially 100% and the baseline for 0 params is 4. The description adds no parameter semantics because there are no parameters, which is appropriate.
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 verifies the FLARELINK_API_KEY and shows the signed-in user, active Cloudflare connection, and project. This specific verb-resource pairing distinguishes it from siblings like stack_overview or scaffold, which serve different purposes.
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 explicitly says 'Call this first to confirm management tools are wired up,' providing clear when-to-use guidance. It does not name alternative tools or explicitly say when not to use it, but the 'first' instruction implies it is a prerequisite for other management tools.
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.
v0.1.2flarelink_cost_patternsflarelink_get_patternflarelink_list_bucketsflarelink_list_databasesflarelink_list_patternsflarelink_list_projectsflarelink_query_databaseflarelink_scaffoldflarelink_sdk_referenceflarelink_stack_overviewflarelink_whoamiScored across 11 tools
Each tool has a clearly distinct purpose: knowledge/guidance tools (stack_overview, scaffold, sdk_reference, cost_patterns) vs. pattern listing/fetching (list_patterns, get_pattern) vs. operational tools (whoami, list_projects, list_databases, query_database, list_buckets). No two tools overlap in functionality, and the list/get/query pattern is clean.
All tools share the 'flarelink_' prefix and use snake_case, but the naming convention is mixed: some are verb_noun (list_patterns, get_pattern, list_projects, query_database, list_buckets) while others are noun-only (stack_overview, sdk_reference, cost_patterns, whoami, scaffold). The inconsistency is minor and readable, but not perfectly uniform.
With 11 tools, the server is well-scoped. The count balances educational/guidance tools with a focused set of management/query tools, each earning its place without redundancy or bloat.
The tool surface covers the core workflows: bootstrapping (scaffold), learning the stack (overview, patterns, SDK reference), verifying access (whoami), and viewing/querying resources (list_*, query_database). Missing operations include create/delete for projects, databases, or buckets, and there's no direct user management, but these gaps are workable via the scaffold and patterns.
Backend for AI-built apps: database, auth, files, email, AI, payments, deploy, realtime. 170+ tools.
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.
The agent-native cloud: database, functions, AI, storage, computers. 50 tools, one API key.
Deploy web apps with sign-in, per-user storage, realtime and AI built in.
