Verified Next.js component scaffolds via remote HTTP MCP, with integrity stamps for Claude/Cursor.
Syncs a project's local clone with its base branch (pulling if it has fallen behind), applies file changes on a new branch, validates the build when the repo is a Node project, and opens a Pull Request for human review. The agent never pushes to the base branch directly. Requires the BotKelp account key that registered the project — fails for a project id you don't own, the same as for an unknown one.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | ||
| prBody | Yes | ||
| prTitle | Yes | ||
| projectId | Yes | ||
| reviewers | No | ||
| botKelpKey | Yes | BotKelp account key (starts with "bk_live_"). Required. | |
| branchName | Yes | Name for the new branch, e.g. agent/add-supabase-auth | |
| githubToken | Yes | GitHub PAT with repo write access, used for the clone/push and the PR. | |
| commitMessage | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly reveals that the tool never pushes to the base branch directly, that it opens a PR for human review, that it validates Node builds, and that it fails for unowned or unknown project IDs. This is strong transparency, though it doesn't cover every edge behavior such as what happens if validation fails.
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 compact and front-loaded with the main workflow in the first sentence and essential failure/auth behavior in the second. There is no filler or repetition. The first sentence is long due to the enumerated steps, but each clause adds necessary information.
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?
The description gives a solid overview of the workflow, safety behavior, and authentication constraints, which is valuable given the absence of annotations and output schema. However, it leaves parameter-level detail underspecified, offers no return-value hints, and doesn't cover what happens on build failure or how extensive the file content expectations are. It is adequate but not fully complete for a complex tool.
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 description coverage is only 33%, so the description must compensate for the six undocumented parameters. It only adds ownership semantics for the BotKelp key and project ID, while saying nothing meaningful about files, commitMessage, prTitle, prBody, reviewers, or githubToken. The parameter behavior it does mention is valuable but far too limited for a 9-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's core purpose: syncing a clone, applying file changes, validating builds, and opening a PR. It distinguishes the operation from any less-specific 'apply changes' notion by describing the exact workflow. No similar sibling tool competes for this behavior, so no additional differentiation is needed.
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 usage context is implied through the described workflow: use this tool to propose changes to a repository via a pull request. However, the description never explicitly states when to use this tool versus an alternative, nor does it provide exclusion criteria. The conditional details (pulling if behind, validating if Node) describe behavior, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Same repo hand-off as get_scaffold_template — a private GitHub repo BotKelp owns and manages itself, plus a short-lived clone credential — but paid per call in USDC via the x402 protocol instead of a BotKelp account: no signup, no API key, callable by any agent with its own wallet. Call once without a payment to receive the price and payment requirements (HTTP 402-style, in the tool result's accepts field), then retry the same call with _meta["x402/payment"] set to a signed x402 payment matching those requirements. You are only charged if the call succeeds.
| Name | Required | Description | Default |
|---|---|---|---|
| components | Yes | Component ids to include, e.g. ["nextjs-base", "tailwind", "supabase-client"]. | |
| projectName | No | Name used in package.json and templates. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, and it excels: it discloses the two-phase payment flow (call without payment to receive requirements, then retry with signed x402 payment), where the payment requirements appear (the tool result's 'accepts' field), and the key charging rule that the caller is only charged if the call succeeds. It also reveals the private-repo and short-lived-credential nature of the result.
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 long but every sentence carries necessary protocol information: the relationship to get_scaffold_template, the payment method, the no-account benefit, and the two-step payment sequence. It front-loads the purpose and then adds operational detail without 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 tool with no output schema, the description explains the payment workflow, the expected first-call response ('accepts' field), and what the caller receives (repo hand-off plus short-lived clone credential). It is nearly complete; a minor gap is that it does not describe the format of a successful final result beyond the hand-off reference.
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 description coverage is 100%, so the schema already documents components and projectName adequately. The description adds essential payment-related guidance via _meta['x402/payment'], but it does not deepen the semantic meaning of the two schema parameters themselves. 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 uses a clear verb+resource ('buy scaffold template') and immediately distinguishes itself from the sibling get_scaffold_template by describing the same repo hand-off but with pay-per-call x402 payment. It is impossible to confuse with generate_scaffold or create_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly names get_scaffold_template as the alternative and explains the key selection factor: pay-per-call via x402 instead of requiring a BotKelp account. It clearly states who should use it (any agent with its own wallet, no signup). It does not explicitly say 'use get_scaffold_template if you have a BotKelp account,' but the contrast is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only, side-effect-free: compares the component versions you currently have pinned against BotKelp's current registry and reports what has newer versions available, plus each component's latest CI freshness status. BotKelp never reads your repo itself — pass the versions you currently have. Call this on whatever schedule you like (daily, weekly, on demand); nothing is pushed or applied automatically. Requires an BotKelp account key with sufficient credit.
| Name | Required | Description | Default |
|---|---|---|---|
| botKelpKey | Yes | BotKelp account key (starts with "bk_live_"). Required. | |
| componentPins | Yes | The component ids and versions you currently have, read from your own local copy. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral burden. It explicitly declares the tool read-only and side-effect-free, notes that BotKelp never reads the user's repo, and states the account key requirement with sufficient credit. This gives an agent a clear safety profile.
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 front-loaded with the core purpose and side-effect declaration, then adds scheduling and auth requirements in dense, purposeful sentences. There is minimal redundancy; every sentence contributes useful information.
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 read-only check tool with only two parameters and no output schema, the description covers what it does, what input the agent must supply, how often it can be called, what side effects it does not have, and the authentication requirement. The output is also summarized (newer versions and CI freshness), so an agent can 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?
Schema coverage is 100%, so the input schema already fully documents both parameters. The description adds context like 'pinned' versions and 'pass the versions you currently have', but this largely restates the schema's own descriptions rather than adding substantial new meaning.
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 uses a specific verb ('compares') and names the exact resource (component versions pinned vs. BotKelp's registry), plus what it reports (newer versions and CI freshness). It also explicitly contrasts with writing or applying changes, distinguishing it from siblings like apply_changes_to_repo.
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?
Clear guidance is given for when to call it ('on whatever schedule you like — daily, weekly, on demand') and that it never pushes or applies changes. However, it does not explicitly name sibling alternatives or state when not to use it in favor of another tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a project: links a GitHub repo the agent will maintain a persistent, synced local clone for, so future tasks can branch off an up-to-date base without re-cloning. Requires a BotKelp account key — projects are private to the account that registers them.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| repoUrl | Yes | GitHub repo URL, e.g. https://github.com/owner/repo | |
| baseBranch | No | Defaults to "main". | |
| botKelpKey | Yes | BotKelp account key (starts with "bk_live_"). Required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden itself. It discloses that a persistent, synced local clone will be maintained, that a BotKelp account key is required, and that projects are private to the registering account. It does not cover idempotency, error cases, or response behavior, but the disclosed side effects are significant and useful.
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 deliver purpose, mechanism, rationale, prerequisite, and privacy in a compact, front-loaded way. Every clause earns its place, and there is no redundant restatement of the tool title.
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?
The description is complete enough for an agent to decide when and how to invoke this tool: it defines the registration side effect, the auth requirement, and account-level privacy. It omits edge-case behavior such as duplicate registrations and return values, but those are not critical for basic 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?
Schema description coverage is 75%, so most parameters are already documented. The description adds little parameter-specific meaning, mostly restating that the botKelpKey is required. The 'name' parameter remains undocumented in both schema and description, though its purpose is fairly self-evident.
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 opens with a specific verb and resource: 'Register a project' and links it to a GitHub repo that will get a persistent, synced local clone. This clearly distinguishes it from sibling tools like list_projects and apply_changes_to_repo. It avoids tautology and explains the actual function.
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 future tasks should branch off an up-to-date cloned base without re-cloning. It also notes prerequisites (BotKelp account key) and privacy scope, but it does not explicitly state when not to use it or name alternative tools for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a Next.js + Supabase + Tailwind project scaffold from the given component ids. Component requires are resolved automatically. Returns the full generated file tree as text so the calling agent can write the files itself. Omit apiKey for Local Mode: free, unauthenticated, files-only generation (no job tracking). Pass apiKey (a premium BotKelp key) to additionally record the attempt as a job. To get a private repo BotKelp manages itself instead of inline files, use get_scaffold_template.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | BotKelp API key (starts with "bk_live_"). Omit for Local Mode — free, unauthenticated, files-only generation. | |
| components | Yes | Component ids to include, e.g. ["nextjs-base", "tailwind", "supabase-client"]. | |
| projectName | No | Name used in package.json and templates. |
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 the Local Mode vs premium behavior, automatic dependency resolution, and that the output is text files the agent writes itself. However, it does not explain rate limits, whether generation is deterministic/overwrites existing files, or what happens with invalid component ids — leaving some behavioral unknowns.
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 compact paragraph that front-loads the core purpose, then adds mode distinctions and sibling guidance. Every sentence adds value, though the multiple clauses in later sentences could be slightly better structured for scanning.
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 no annotations, 3 params with 100% schema coverage, and no output schema, the description is fairly complete: it covers purpose, mode differences, and output format. It lacks error/edge-case behavior and post-call expectations, but for a scaffolding tool the main operational context is provided.
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 parameters are already fully documented in the schema. The description adds context around the apiKey parameter's behavior (Local Mode vs job tracking) but does not add meaning beyond the schema for components or projectName. 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 it generates a Next.js + Supabase + Tailwind scaffold from component ids, resolves requires, and returns the file tree as text. It distinguishes itself from siblings by explicitly naming get_scaffold_template as the alternative for a BotKelp-managed private repo and contrasting Local Mode vs premium job tracking.
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 gives explicit when-to-use guidance: Local Mode when omitting apiKey for free files-only generation, premium mode when passing apiKey to record a job, and points to get_scaffold_template for a private repo instead of inline files. This is stronger than most sibling descriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Requests a build for the given component ids, backed by a private GitHub repo BotKelp owns and manages itself under its own org — never your account. Returns the repo's location and a short-lived, single-repo-scoped clone credential; clone it yourself, BotKelp never touches wherever you copy it to. Repeat requests for the same component combination reuse the same repo at no extra GitHub-side cost. Requires an BotKelp account key with sufficient credit — there is no free/local mode for this tool (see generate_scaffold for that). See check_component_updates to find out when a newer combination is available.
| Name | Required | Description | Default |
|---|---|---|---|
| botKelpKey | Yes | BotKelp account key (starts with "bk_live_"). Required. | |
| components | Yes | Component ids to include, e.g. ["nextjs-base", "tailwind", "supabase-client"]. | |
| projectName | No | Name used in package.json and templates. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well. It discloses ownership, credential scoping and lifetime, the fact that BotKelp never touches the cloned destination, repeat-request reuse, and the account-key credit requirement.
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 dense but every sentence adds necessary context: what is built, where it lives, how to clone it, reuse behavior, and credit requirements. The core action and outcome are front-loaded, and there is 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?
Since there is no output schema and no annotations, the description must explain return values and operational constraints, and it does: repo location, short-lived scoped credential, no free mode, credit requirement, and related tools. This is sufficient for an agent to invoke the tool correctly and know what to expect.
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 parameters are already well-documented. The description adds meaningful behavioral context about component combinations being reused and no extra GitHub-side cost for repeat requests, which enriches the component parameter semantics beyond the 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 states a specific action (requests a build for component ids), the resource (a private GitHub repo owned by BotKelp), and the outcome (returns repo location and clone credential). It clearly distinguishes itself from generate_scaffold by noting the paid vs free/local difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says there is no free/local mode and points to generate_scaffold for that alternative, giving the agent a clear when-not-to-use condition. It also references check_component_updates for determining when a newer combination is available, which guides follow-up usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the projects registered by this BotKelp account. Requires a BotKelp account key — never returns another account's projects.
| Name | Required | Description | Default |
|---|---|---|---|
| botKelpKey | Yes | BotKelp account key (starts with "bk_live_"). Required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does usefully disclose that an account key is required and that the tool never returns another account's projects. It does not go into response shape or invalid-key behavior, but it provides the key behavioral constraints for a simple list 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?
Two short sentences deliver the core action, the auth requirement, and the account-scoping guarantee with no filler. The most important facts are 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?
For a one-parameter, no-output-schema tool, the description covers what an agent needs to decide to call it and what to pass. It could mention the return shape more explicitly, but 'List the projects' plus the account-scope caveat is adequate.
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 already fully documents botKelpKey, including its 'bk_live_' prefix and that it is required, so the description adds no new parameter-level meaning. Schema coverage is 100%, so the baseline of 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 states a specific action and resource — 'List the projects registered by this BotKelp account' — and clearly scopes it to the authenticated account, which separates it from sibling tools like create_project and get_scaffold_template. The added privacy boundary reinforces what the tool does rather than merely echoing the title.
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 makes the intended context clear: use it to retrieve only the current account's projects, and it requires a BotKelp account key. It does not explicitly name alternative tools or say when not to use it, but the read-versus-create contrast with siblings is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the BotKelp component registry (Next.js/Supabase/Tailwind "Lego blocks"). Returns id, name, version, description, requires, conflictsWith, provides (capability tags, e.g. "authentication"), dependencies, envVariables, sources (docs/github-releases/github-examples citations proving this component was checked against real, current official material — not written from memory), and a freshness field (status/checkedAt/outdatedDependencies from the latest automated build check, or null if never validated) for each match — check freshness before relying on a component. Filter by free-text query and/or by provides capability tags (e.g. ["authentication"]) to discover components by what they do rather than needing to already know their ids. Call with no arguments to list everything.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Free-text filter matched against component id, name, and description. | |
| provides | No | Only return components whose `provides` includes every tag listed here, e.g. ["authentication"] or ["billing", "subscription-management"]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does this well: it enumerates return fields, calls out the freshness field and warns to check it before relying on a component, and explains the provenance of the sources field. The verb 'Search' implies a read-only operation, and no contradictory or hidden behavior is indicated.
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 long but every sentence contributes value: registry identity, return fields, freshness caveat, filter semantics, and no-argument behavior. The core action is front-loaded, and the detail is organized clearly. While it could be tightened slightly, it is dense rather than padded.
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 no output schema and no annotations, the description is thorough: it covers return fields, filter behavior, the no-arguments case, and a critical caveat about freshness. Minor omissions like pagination, sorting, or empty-result behavior are acceptable for a search tool and do not undermine selection or 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 description coverage is 100%, so the baseline is 3. The description reinforces the query and provides parameters with examples and conceptual framing ('discover components by what they do rather than needing to already know their ids'), but it does not add substantial parameter-level information beyond what the schema already documents.
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 starts with a specific verb and resource: 'Search the BotKelp component registry' and further identifies the component types (Next.js/Supabase/Tailwind 'Lego blocks'). It clearly distinguishes the tool from siblings like check_component_updates by describing the registry, search semantics, and rich return fields.
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 explicit usage guidance: filter by free-text query and/or provides capabilities to discover components by function, and call with no arguments to list everything. It does not explicitly name alternative tools or state when not to use this tool, but the context is clear enough for an agent to know when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs a real npm install && npm run build against the given files and reports whether the project builds. Free, no API key needed. Use it after editing a generate_scaffold result (e.g. wiring a component into a page) before handing the project to the user. The build runs asynchronously: call once with files (the full project — every file, not just the ones you changed) and you get back status "WAIT" and a jobId; call again with that jobId until you get "OK" (it builds) or "FAIL" (it does not, with the compiler error). A build usually takes one to two minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | The full project to verify — generate_scaffold's `files` output with your edits applied. Provide this to start a verification. | |
| jobId | No | A job id from a previous WAIT response. Provide this to check a verification already started. | |
| envVariables | No | Env var names to write placeholder values for before building (typically generate_scaffold's `envVariables` output) — needed for components that read process.env at build time (e.g. a Supabase client). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: it discloses that it runs a real build, requires no API key, is asynchronous with WAIT/OK/FAIL responses, and typically takes one to two minutes. This is exactly the kind of behavioral context an agent needs.
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 longer than strictly minimal, but every sentence earns its place: core purpose, usage context, async protocol, timing, and parameter guidance. It is front-loaded with the primary action and remains well-structured.
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 no annotations and no output schema, the description is remarkably complete. It covers the tool's operation, the async workflow, return states, expected duration, and parameter usage. An agent has enough information to call it correctly on the first attempt and to poll for completion.
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 description coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema by emphasizing that `files` must be the full project, not just changed files, and by explaining how `jobId` is used across polling calls. This raises it above baseline.
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 states a specific verb and resource: it runs a real `npm install && npm run build` against given files and reports whether the project builds. This clearly distinguishes it from siblings like `generate_scaffold` or `get_scaffold_template`.
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 gives an explicit when-to-use instruction: after editing a `generate_scaffold` result, before handing the project to the user. It also explains the async polling workflow and timing, leaving no ambiguity about how to invoke it across calls.
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. Dates show when Glama detected each change.
apply_changes_to_repobuy_scaffold_templatecheck_component_updatescreate_projectgenerate_scaffoldget_scaffold_templatelist_projectssearch_componentsverify_scaffoldClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Deploy AI-generated HTML/CSS/JS to instant public HTTPS URLs from any MCP-compatible agent.
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
Pre-flight MCP security. Blocks compromised deps + tool drift. HMAC-signed. Dredd judges.
AI website builder (Wix/Framer alt). SlateHut MCP over HTTP: tools, schemas. Bearer auth.
Add one secure layer between your agents and this server.
Most tools target clearly distinct actions: search/check are read-only registry operations, generate/get/buy are different scaffold delivery modes, and create/list/apply/verify handle project lifecycle. The main ambiguity is between get_scaffold_template and buy_scaffold_template, which share the same repo-handoff behavior and differ only in payment/account requirements; the descriptions are detailed enough to tell them apart, but an agent could still pick the wrong one without reading carefully.
Every tool follows a consistent verb_noun snake_case pattern: search_components, create_project, generate_scaffold, verify_scaffold, apply_changes_to_repo, and so on. The verbs are specific and the nouns map cleanly to the resources being acted on, making the toolset predictable.
Nine tools is well-scoped for a scaffolding and component-registry service. Each tool covers a meaningful part of the workflow—discovery, generation, delivery, verification, project registration, and repository updates—without redundancy or excessive granularity.
The core domain is well covered: component discovery, update checking, scaffold generation in three delivery modes, build verification, project registration, and applying changes to a repo. Minor gaps exist—there is no project deletion/unregistration, no way to fetch a single project's details beyond list_projects, and no direct update action after check_component_updates reports newer versions—but agents can work around these without major dead ends.