Build a working web app from a prompt, then deploy it to a live URL.
Build a working web app from a prompt with PromptUI. Starts an asynchronous build (costs credits from the authenticated account) and returns a buildId — poll get_build_status for progress and the preview link.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Build mode: 'quality' (default) or 'fast' | quality |
| prompt | Yes | What to build, in plain language | |
| framework | No | Output framework: 'react-spa' (default) or 'nextjs-app' | react-spa |
| _confirmed | No | Set to true only after the user has explicitly approved this exact write or credit-spending action. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly=false, idempotent=false), the description discloses that the build is asynchronous, spends credits on the authenticated account, and returns a buildId. This is meaningful behavior an agent cannot infer from the schema alone.
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, with the core action first and the async follow-up second. Every clause adds information: what it builds, what it costs, what it returns, and what to call next.
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 required parameter and rich schema descriptions, the description covers the critical non-schema facts: async behavior, credit cost, the buildId return value, and the get_build_status polling path. No essential guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents prompt, mode, framework, and the confirmation flag. The description adds no parameter-level detail beyond that, matching the baseline for a fully documented 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 names a specific action ('Build a working web app'), the input source ('from a prompt'), and the key output ('returns a buildId'). It distinguishes itself from siblings like get_build_status by explicitly pointing to that tool for polling progress.
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 clear operational context: this is the asynchronous, credit-costing first step for creating an app, with get_build_status as the follow-up. It stops short of naming explicit when-not-to-use conditions or alternative build approaches, so it does not earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deploy a completed PromptUI build to a live URL. The first deploy of each app is charged; redeploying that same app is free.
| Name | Required | Description | Default |
|---|---|---|---|
| buildId | Yes | The buildId of a completed build | |
| _confirmed | No | Set to true only after the user has explicitly approved this exact write or credit-spending action. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include idempotentHint=true, which the description reinforces by stating redeploys are free—adding cost context beyond the structured hints. The description also discloses the paid action ('first deploy charged') which is critical behavioral information. A slight lack: it doesn't describe what happens to the previous deployment or whether the tool waits for success, but the 'charged' disclosure is valuable.
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, both informative and front-loaded with the core action. The cost note is relevant context and earns its place. Slightly more could be said about the 'confirmed' parameter, but the description remains tight and focused.
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 a simple 2-parameter schema, no output schema, and annotations already carrying safety hints, the description covers the key behavior: deploy, cost, and idempotency. It's missing guidance on what constitutes 'completed' (e.g., build status check) and any note on expected response or failure modes, but for a simple deployment tool the essentials are present.
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 both parameters. The description does not add extra meaning beyond the schema's 'completed build' context, but the base rate is 3 because the schema handles it. The description's phrase 'completed PromptUI build' clarifies that buildId must reference a finished build, which is a small addition.
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—deploying a completed PromptUI build to a live URL—with enough clarity to identify the tool's primary function. It distinguishes itself from build_app (which builds) and gtm_publish_content (which publishes content) through the explicit 'completed PromptUI build' and 'live URL' phrasing, though it doesn't name siblings directly.
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 usage context: it must be a completed build, and the first deploy is charged while redeploys are free. This gives an implicit condition for when to use the tool (after a build completes) and hints at cost considerations, but it doesn't explicitly state alternatives or when not to use it beyond the implicit 'completed build'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Echo back the input (for testing MCP integration)
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Message to echo |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds no behavioral detail beyond what the name and schema already imply; it does not describe return format or side effects, though none are expected for an echo 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 a single compact sentence that states the action and purpose with zero filler. It is front-loaded and immediately understandable.
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 trivial one-parameter tool with strong safety annotations, the description is fully adequate. It states what the tool does, why it exists, and the input is fully described in the 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?
Schema description coverage is 100%, with the 'message' parameter fully documented as 'Message to echo'. The description adds no extra parameter-level meaning, 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?
The description clearly states the tool's action ('Echo back the input') and its purpose ('for testing MCP integration'). This distinguishes it from the unrelated sibling tools and leaves no ambiguity about when it applies.
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 'for testing MCP integration' phrase provides clear context for when this tool should be used. It does not explicitly mention alternatives or exclusions, but the sibling tools are domain-specific and clearly unrelated, so the usage context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of a PromptUI build started with build_app. Returns building / needs_clarification / completed (with a shareable previewUrl) / failed.
| Name | Required | Description | Default |
|---|---|---|---|
| buildId | Yes | The buildId returned by build_app |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't need to restate safety. It adds meaningful behavioral detail by listing the possible outcomes (building, needs_clarification, completed with previewUrl, failed), which goes beyond the annotations and tells the agent what to expect from the call.
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 entire description is one focused sentence that front-loads the action and resource, then efficiently lists the return states. Every part contributes to agent understanding with no filler or repetition of schema details.
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 low-complexity tool with a single documented parameter and only four possible outcomes, all of which the description names. Since there is no output schema, listing the statuses is essential and is done well. Minor gaps remain around error cases like an unknown buildId, but they are not critical for a simple status checker.
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%, and the schema already documents buildId as 'The buildId returned by build_app'. The description references the same relationship but adds no new detail about the parameter's format, constraints, or usage beyond what the schema provides, so 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 names a specific verb ('Check'), a specific resource ('status of a PromptUI build'), and explicitly ties it to builds started with build_app. It also enumerates the possible status values, making the tool's purpose unmistakable and distinguishing it from build_app and list_builds.
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 clearly implies when to use this tool: after build_app, to check the resulting build's status. It does not explicitly contrast with list_builds or state when not to use it, but the 'started with build_app' condition provides enough contextual guidance for an agent to select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate and persist a new GTM content draft for the authenticated user.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of variants to generate (1-20) | |
| channel | No | Delivery channel. One of: x|linkedin|facebook|instagram|youtube|email|web | x |
| language | No | Optional language | |
| appSource | No | promptui | custom session id | promptui |
| _confirmed | No | Set to true only after the user has explicitly approved this exact write or credit-spending action. | |
| campaignId | No | Optional campaign id | |
| contentClass | No | Content class. One of: product_led|brand_led|domain_led|offer_led | product_led |
| operatorPrompt | No | Optional operator instruction for the generator | |
| deliverableType | No | Deliverable type. One of: post|thread|launch_pack|bio|promo_campaign|educational_series|landing_copy|cinematic_video_teaser|visual_brief|seo_blog_post|seo_landing_page|llms_txt | post |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'persist' and 'authenticated user' context, confirming a write side effect and user scoping beyond the annotations' readOnlyHint=false. However, it does not disclose that this action may spend credits or require explicit user confirmation via _confirmed, which is meaningful behavioral context for a non-idempotent mutation.
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 filler. It efficiently communicates the core action and scope, though it is terse enough that some behavioral and usage information is left out.
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 having 9 parameters, no output schema, and non-trivial write/credit implications, the description is only a purpose statement. It does not explain when to use it, what the returned draft looks like, how confirmation works, or the relationship to channels and deliverable types. The schema covers parameter syntax, but the description leaves important operational context unaddressed.
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 all 9 parameters. The description does not need to repeat parameter details and adds only the high-level notion of a 'content draft,' which provides minimal extra meaning 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 uses a specific verb and object: 'Generate and persist a new GTM content draft,' and clarifies scope with 'for the authenticated user.' This differentiates it from sibling tools like gtm_list_content and gtm_publish_content at a high level, though it does not explicitly name them.
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?
There is no guidance about when to use this tool versus alternatives such as gtm_publish_content or gtm_list_content. The only clue is the word 'generate,' which implies creating a draft, but no explicit conditions, exclusions, or comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read current PromptUI GTM channel analytics. X and YouTube can include live public metrics; other channels use PromptUI publish history.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only and idempotent behavior. The description adds meaningful freshness detail: X and YouTube may show live public metrics while other channels rely on PromptUI publish history. This is useful behavioral context beyond the annotations and does not contradict them.
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 sentences with the core action and scope front-loaded. Every sentence adds value: the first defines what the tool reads, the second explains data-source expectations.
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, read-only analytics tool with rich annotations, the description is sufficiently complete. It explains the data source and freshness behavior, and the low complexity means no return-shape detail is necessary 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?
The input schema has zero parameters and 100% description coverage, so the description bears no parameter-documentation burden. The empty schema is unambiguous and needs no elaboration.
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?
Description clearly states the verb 'Read' and specific resource 'current PromptUI GTM channel analytics'. It also distinguishes itself from sibling GTM content tools by focusing on analytics rather than content generation, listing, or publishing.
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 read-only analytics use case clear, and the sibling tools are all content-oriented, so selection is unambiguous. It doesn't explicitly say 'use this instead of X', but the context is strong enough that an agent can route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List GTM queue items for the authenticated PromptUI user.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items (default 20, max 100) | |
| status | No | Optional status filter: draft|in_review|approved|vetoed|scheduled|published|archived | |
| channel | No | Optional channel filter: x|linkedin|facebook|instagram|youtube|email|web | |
| campaignId | No | Optional campaign id filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and idempotentHint true, and the description is consistent with those. It adds useful behavioral context by noting the result is scoped to the authenticated PromptUI user. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or duplication of schema details. Every word earns its place.
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 read-only list operation with fully documented parameters, the description is mostly sufficient. However, there is no output schema, and the description does not indicate the return shape or what fields a GTM queue item contains, leaving some ambiguity about the response.
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?
All four parameters are fully documented in the input schema, including defaults, max, and allowed values, so the schema carries the parameter-semantics burden. The description adds no additional parameter-level meaning, which is acceptable given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List'), a specific resource ('GTM queue items'), and a clear scope ('for the authenticated PromptUI user'). This differentiates it from sibling tools like gtm_generate_content and gtm_publish_content without needing to open the 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?
The purpose statement implies it should be used when retrieving the user's GTM queue items, but there is no explicit guidance about when to use this tool over alternatives or when not to use it. Siblings such as gtm_get_analytics could also serve read-like purposes, yet no distinction is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish one GTM content item to a connected social platform.
| Name | Required | Description | Default |
|---|---|---|---|
| pageId | No | Optional LinkedIn/Facebook page target id | |
| igUserId | No | Optional Instagram user id target | |
| platform | No | Optional platform override: x|linkedin|facebook|instagram|tiktok | |
| contentId | Yes | GTM content id to publish | |
| _confirmed | No | Set to true only after the user has explicitly approved this exact write or credit-spending action. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the annotations: readOnlyHint=false marks this as a write operation, and publishing to a connected social platform conveys an external side effect. However, it does not disclose irreversibility, credit spending, or the need for explicit confirmation, though the _confirmed parameter's schema note partially covers that 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 a single, front-loaded sentence with no filler or restatement of the full schema. It conveys the core action clearly and economically.
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 an external, side-effecting publish action with five parameters and no output schema, yet the description omits expected result, confirmation workflow, default platform behavior, and preconditions. The _confirmed parameter is visible in the schema, but the tool-level description alone is too thin for an agent to safely invoke a credit-spending publish call.
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 even though the description adds no per-parameter details. The phrase 'one GTM content item' and 'connected social platform' lightly reinforces contentId and platform intent but does not explain how pageId, igUserId, or platform override interact.
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 — 'Publish one GTM content item to a connected social platform' — with a clear verb, object, and destination. This differentiates it from the generation, listing, and analytics sibling tools without needing to name them.
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 no guidance on when to use this tool versus alternatives or what workflow should precede it. It does not mention that publishing should follow content generation/review, nor does it provide exclusions or conditions around platform targeting or user confirmation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the authenticated user's recent PromptUI builds with their statuses.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum builds to return (default 10, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds useful context beyond annotations: authentication and user scoping ('authenticated user's') and that the response includes statuses for each build. It does not describe pagination or empty-result behavior, but the schema already provides limit details.
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?
One sentence with no filler. The verb and resource are front-loaded, and the clause 'with their statuses' adds return-value context that helps the agent understand the operation's purpose.
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 read-only list tool with one optional parameter and no output schema, the description is largely complete: it states user scope, resource type, recency, and returned fields. The only gap is not explicitly routing to get_build_status for single-build lookups, which is minor given sibling names are visible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers the only parameter (limit) fully with type, default, and max, so the description need not repeat it. Baseline 3 applies; the description offers no additional 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?
States a specific verb ('List'), resource ('the authenticated user's recent PromptUI builds'), and what is returned ('with their statuses'). The plural 'builds' and inclusion of statuses clearly differentiate it from sibling get_build_status, which implies a single build lookup.
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 when to use this tool: to enumerate recent builds and their statuses. However, it does not explicitly mention the obvious alternative get_build_status or give an exclusion, leaving the agent to infer the distinction between listing and fetching a single build's status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get production-quality shadcn/ui component code pre-adapted for the Sandpack preview environment. Available components: accordion, dropdown_menu, dialog, sheet, tooltip, progress, separator, scroll_area, skeleton, alert. Returns ready-to-use JS code with correct imports. Use this instead of building complex UI primitives from scratch.
| Name | Required | Description | Default |
|---|---|---|---|
| component | Yes | Component name to fetch. One of: accordion, dropdown_menu, dialog, sheet, tooltip, progress, separator, scroll_area, skeleton, alert |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint and idempotentHint annotations already covering the safety profile, the description adds useful behavioral context: components are 'pre-adapted for the Sandpack preview environment' and the output is 'ready-to-use JS code with correct imports.' This goes beyond the annotations to clarify what the caller receives.
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?
Four short sentences, each earning its place: purpose and environment, component inventory, output guarantee, and usage guidance. The key differentiator ('Sandpack preview environment') is front-loaded, and there is no redundant or filler content.
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 read-only tool with one fully documented parameter and no output schema, the description is complete. It tells the agent exactly which components are available, what the returned code looks like, that it is pre-adapted for the target environment, and when to choose this tool over manual implementation.
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 fully documents the 'component' parameter, including the allowed values. The description restates the component list but does not add additional meaning, format details, or examples beyond what the schema provides. 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 specific verb ('Get') and identifies the exact resource ('shadcn/ui component code') with an explicit list of available components. It clearly differentiates from all sibling tools, none of which fetch component code, by adding the unique Sandpack adaptation detail.
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 final sentence provides explicit guidance: 'Use this instead of building complex UI primitives from scratch.' This clearly states when the tool is appropriate, though it does not enumerate when-not-to-use scenarios or name an alternative sibling tool, as no sibling overlaps with this functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Research the live web: search for information, read documentation, fetch API references, or verify library usage. Returns structured findings as markdown.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | What to research or look up on the web | |
| urls | No | Specific URLs to visit (optional — if omitted, will search the web) | |
| maxPages | No | Max pages to fetch content from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful behavioral context by saying 'live web' and 'Returns structured findings as markdown,' which informs the agent that results may reflect real-time external content and come in a particular format. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. It front-loads the core action ('Research the live web'), lists representative use cases, and ends with the output format. Every sentence earns its place.
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 read-only web research tool with three well-documented parameters and no output schema, the description is sufficiently complete. It explains what the tool does, the kinds of tasks it supports, and the markdown output. It could slightly expand on how the optional urls parameter interacts with the default search behavior, but the schema covers that well enough.
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 explains all three parameters: goal, urls, and maxPages. The description adds overall purpose but does not enrich individual parameter semantics beyond the schema, 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 uses a specific verb-resource pairing ('Research the live web') and names concrete use cases: search for information, read documentation, fetch API references, verify library usage. This clearly distinguishes web_scout from the sibling tools like db_query and deploy_app, which are about entirely different resources.
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 on when to use the tool: research on the live web, documentation, API references, or library verification. It does not explicitly list exclusions or name alternative tools, but the domain is obvious enough relative to siblings, so it earns a 4 rather than a 5.
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.
build_app1 field changedInput schema / properties / _confirmedAdded value: +{
+ "default": false,
+ "description": "Set to true only after the user has explicitly approved this exact write or credit-spending action.",
+ "type": "boolean"
+}db_querydeploy_app1 field changedInput schema / properties / _confirmedAdded value: +{
+ "default": false,
+ "description": "Set to true only after the user has explicitly approved this exact write or credit-spending action.",
+ "type": "boolean"
+}gtm_generate_content1 field changedInput schema / properties / _confirmedAdded value: +{
+ "default": false,
+ "description": "Set to true only after the user has explicitly approved this exact write or credit-spending action.",
+ "type": "boolean"
+}gtm_publish_content1 field changedInput schema / properties / _confirmedAdded value: +{
+ "default": false,
+ "description": "Set to true only after the user has explicitly approved this exact write or credit-spending action.",
+ "type": "boolean"
+}build_appdb_querydeploy_appechoget_build_statusgtm_generate_contentgtm_get_analyticsgtm_list_contentgtm_publish_contentlist_buildsshadcn_uiweb_scoutClaiming 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 a live web app from one sentence. build_app + poll to a public HTTPS URL you own.
Deploy the small apps your agent builds: one tool call returns a live, private shareable HTTPS link.
Talk to Claude and get a live web app deployed to a real URL, with Postgres, storage and cron.
AppDeploy turns app ideas described in AI chat into live full-stack web applications
Add one secure layer between your agents and this server.
Each tool maps to a distinct action/resource: build lifecycle (build/deploy/status/list), GTM content workflow (generate/list/publish/analytics), and utility helpers (echo/shadcn_ui/web_scout) are clearly separated. Even closely related tools like get_build_status and list_builds differ in specificity.
Most tools follow a snake_case verb_noun pattern like build_app, deploy_app, and gtm_publish_content. Echo, shadcn_ui, and web_scout break the pattern but remain recognizable and do not create confusion.
11 tools cover the build workflow, GTM workflow, and a few support utilities without redundancy or bloat. The count is well within the ideal range and each tool earns its place.
The main build and GTM workflows are represented, but there is no tool to respond when get_build_status returns needs_clarification, leaving a potential dead end. Content editing/deletion and build deletion are also absent, though this may be acceptable if drafts and builds are treated as immutable.
