BetaFinds
Server Details
Publish and update your startup on BetaFinds from an AI agent — listings, changelog, releases.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- pendurov/betafinds-mcp
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 14 of 14 tools scored.
Every tool has a clear, distinct purpose: startup CRUD, stage management, release handling, image upload, category listing, updates, reviews, waitlist. No overlapping ambiguities.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_startup, list_categories, upload_image). No mixing of conventions.
14 tools is well-scoped for a startup management platform. Each tool serves a specific function without redundancy, covering core workflows.
Covers the full lifecycle: create, update, stage transitions, launch, releases, file uploads, images, categories, updates, waitlist, and reviews. Missing delete startup or team management, but these are minor gaps.
Available Tools
14 toolsannounce_launchAInspect
Announce your startup's official launch: the stage becomes LAUNCHED, a LAUNCH update is published, and waitlist members are notified (once). A working product link is required (url or an already saved store link).
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Working product link (if not set yet) | |
| body | Yes | Description of the first public version, Markdown (10–20000 characters) | |
| title | Yes | Launch headline (3–200 characters) | |
| startup_slug | Yes | Startup slug (from list_my_startups) | |
| notify_waitlist | No | Notify the waitlist (default true) |
Output Schema
| Name | Required | Description |
|---|---|---|
| slug | No | |
| stage | No | |
| message | No | |
| firstLaunch | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is mutating (readOnlyHint false) and not destructive (destructiveHint false). The description goes beyond by specifying what mutations occur: stage change, update published, and waitlist notification (once). It also notes the requirement of a working product link. However, it does not mention whether the launch can be undone or if the stage change is irreversible.
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, front-loaded with the purpose and effects, then a key requirement. No unnecessary words. Every sentence adds value.
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 complexity (5 parameters, output schema exists, sibling tools), the description covers the main effects and a critical requirement. It's missing the fact that the tool is likely a one-time action per startup (only notification is noted as once) and any preconditions (e.g., startup must not already be launched). Still, it provides enough context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, setting a baseline of 3. The description adds value by clarifying the 'url' parameter: a working product link is required, either via the url parameter or an already saved store link. This provides context beyond the schema description, which only says 'Working product link (if not set yet)'. Other parameters are well-described in 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 clearly states the tool's purpose: announcing a startup's official launch. It lists the specific effects: stage becomes LAUNCHED, a LAUNCH update is published, and waitlist members are notified once. This distinguishes it from sibling tools like 'publish_update' (which just publishes an update) and 'change_startup_stage' (which changes stage without the other actions).
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 this tool is for official launches, not for regular updates or stage changes. It mentions that a working product link is required, which adds context. However, it does not explicitly contrast with sibling tools or state when not to use it (e.g., if only a stage change or update is needed without launching). Clear context but no exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
change_startup_stageAIdempotentInspect
Change your startup's product stage: PRELAUNCH — preparing to launch, BETA — recruiting beta testers, PAUSED — development paused (requires public_note). To move to LAUNCHED use announce_launch. Allowed transitions: PRELAUNCH→BETA/PAUSED, BETA→PAUSED, PAUSED→PRELAUNCH/BETA.
| Name | Required | Description | Default |
|---|---|---|---|
| stage | Yes | New stage | |
| public_note | No | Public note (required for PAUSED, up to 500 characters) | |
| startup_slug | Yes | Startup slug (from list_my_startups) |
Output Schema
| Name | Required | Description |
|---|---|---|
| slug | No | |
| stage | No | |
| message | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and destructiveHint=false. The description adds behavioral context: allowed transitions, requirement of 'public_note' for PAUSED stage, and the meaning of each stage. This goes beyond annotations by clarifying constraints and effects.
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 compact sentences with no redundancy. The information is front-loaded and efficiently structured, listing stages and transitions without wasted 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?
Given the tool's moderate complexity, the description covers purpose, usage context, allowed transitions, parameter requirements, and distinguishes from a sibling. With an output schema presumed present, this is fully sufficient for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds value by explaining the stages and transition rules, which the schema's enum descriptions do not fully capture. It also clarifies that 'public_note' is required for PAUSED.
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 purpose: 'Change your startup's product stage.' It enumerates the specific stages (PRELAUNCH, BETA, PAUSED) with brief explanations, and distinguishes itself from sibling tool 'announce_launch' for the LAUNCHED stage.
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 provided: when to use this tool vs. alternatives ('To move to LAUNCHED use announce_launch'), and allowed transitions between stages are listed. This helps the agent decide correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
complete_asset_uploadAIdempotentInspect
Confirm that the release file has been uploaded. Verifies the file's presence and size in storage and makes it available for download.
| Name | Required | Description | Default |
|---|---|---|---|
| asset_id | Yes | File ID from request_asset_upload |
Output Schema
| Name | Required | Description |
|---|---|---|
| downloadUrl | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds verification and availability steps beyond annotations. Annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true) are consistent. Could explicitly state idempotency, but overall good.
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 with no wasted words. Front-loads the main action and provides necessary 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?
Simple tool with one param and output schema present. Description covers purpose, verification, and effect. Output schema handles return values, so no need to describe them.
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?
Only one parameter, fully described in schema. Description adds no additional meaning beyond 'File ID from request_asset_upload'. Baseline score due to high 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?
Description clearly states the tool confirms upload completion, verifies presence and size, and makes file available. Specific verb (confirm, verifies, makes available) and resource (release file) distinguish it from siblings like request_asset_upload.
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?
Implies usage after requesting upload and actual file transfer, but no explicit when-not-to-use or comparison with siblings. Context with request_asset_upload makes it clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_releaseAInspect
Create a release (version) of your startup. By default also publishes a RELEASE-type update with the notes text. After creation, upload files via request_asset_upload.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Release notes in Markdown | |
| version | Yes | Version, e.g. 1.4.0 | |
| announce | No | Whether to publish an update in the feed (default true) | |
| startup_slug | Yes | Startup slug |
Output Schema
| Name | Required | Description |
|---|---|---|
| message | No | |
| version | No | |
| release_id | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it's not read-only or destructive, and the description adds that a RELEASE-type update is published by default, with file uploads required afterward. This is sufficient behavioral context beyond 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 consists of two sentences with no wasted words. It front-loads the main action and default behavior, then gives a clear follow-up instruction. Every sentence serves a 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?
The description covers the main action, default behavior, and necessary next step (file upload). Given the presence of an output schema and accurate annotations, the description is complete for an agent to understand 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%, so all 4 parameters are documented. The description only indirectly references 'notes text' and does not add new constraints, examples, or clarifications beyond what the schema provides.
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 creates a release (version) of a startup and distinguishes it from siblings by noting it also publishes a RELEASE-type update. This verb-resource pairing is specific and unambiguous.
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 mentions the default publish behavior and the post-creation step of uploading files via request_asset_upload, but does not explicitly specify when to use this tool versus alternatives like publish_update or upload_image. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_startupAInspect
Create a new startup on BetaFinds (submitted for review). Upload the logo and screenshots first via upload_image (or POST https://betafinds.com/api/v1/images) and pass the returned URLs here. Set the category by slug — get the list via list_categories (a category name also works, case-insensitive).
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Product website URL (required for stage=LAUNCHED, optional for prelaunch) | |
| logo | No | Logo URL from upload_image (optional) | |
| name | Yes | Product name | |
| tags | No | Tags (up to 6) | |
| stage | No | Product stage: PRELAUNCH — preparing to launch, BETA — recruiting beta testers, LAUNCHED — already launched (default) | |
| tagline | Yes | One-line tagline (up to 160 characters) | |
| appStoreUrl | No | App Store page link (iOS) | |
| description | Yes | Full description (min 50 characters) | |
| screenshots | No | Screenshot URLs from upload_image (up to 5, optional) | |
| category_slug | No | Category slug (e.g. ai, saas, fintech) | |
| googlePlayUrl | No | Google Play page link (Android) | |
| testflightUrl | No | TestFlight link (iOS beta) | |
| prelaunch_ready | No | What is already done: prototype, design, private beta… (up to 1000 characters) | |
| prelaunch_promise | No | What a waitlist subscriber will get (up to 1000 characters) | |
| prelaunch_audience | No | Who the product is for (up to 1000 characters) | |
| target_launch_date | No | Estimated launch date in YYYY-MM-DD format (for prelaunch; empty string clears it) |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | No | |
| slug | No | |
| status | No | |
| message | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the startup goes into review (submitted for review), and gives prerequisites for assets. Annotations indicate mutation but not destructive; description adds context about submission process.
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 purpose and result, then usage tips. No unnecessary 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?
With output schema, high parameter coverage, and annotations, description covers review process and dependencies. Could mention defaults (e.g., stage default) but overall 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?
Schema coverage is 100%, so baseline 3 applies. Description adds value for logo, screenshots, and category_slug but does not elaborate on other parameters beyond schema 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?
Description clearly states 'Create a new startup on BetaFinds (submitted for review)', with specific verb and resource, and distinguishes from siblings like update_startup.
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 explicit guidance to upload logo/screenshots first via upload_image and set category via list_categories, but no explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_releasesARead-onlyIdempotentInspect
Список опубликованных релизов стартапа с файлами. Для LAUNCHED-проектов downloadUrl — постоянная прямая ссылка. На закрытых стадиях ссылка возвращается только для своих стартапов или где у вас открыт доступ (иначе locked=true, downloadUrl=null).
| Name | Required | Description | Default |
|---|---|---|---|
| startup_slug | Yes | Startup slug |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, destructiveHint), the description adds critical behavioral context: downloadUrl behavior depends on startup stage and user access, with locked=true when access is restricted. This explains conditional output, which is valuable for the agent.
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, front-loaded with the main purpose and followed by a key behavioral detail. Every word contributes meaning; no 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?
Given the tool's simplicity (one parameter, read-only, has output schema), the description covers the main purpose and a significant behavioral nuance (locked vs direct links). With output schema present, return format is not required. The description is complete for agent decision-making.
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 only parameter, startup_slug, is fully described in the schema (100% coverage). The description does not add additional meaning or constraints beyond referencing startups in general. Schema coverage is high, so baseline score 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 clearly states the tool lists published releases of a startup with files, using specific verbs and resource. It distinguishes from siblings like create_release and announce_launch by focusing on read operations and providing details about download URL behavior based on startup stage.
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 explains the behavior of downloadUrl under different startup stages, which helps users understand when results may be locked. However, it does not explicitly state when to use this tool versus alternatives like get_waitlist or list_categories, so usage guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_store_reviewsARead-onlyIdempotentInspect
Public Google Play and App Store reviews of your startup: monitoring state per store and the latest reviews (rating, text, developer response). Reviews are collected automatically via the app links.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page (20 reviews each, default 1) | |
| startup_slug | Yes | Startup slug (from list_my_startups) |
Output Schema
| Name | Required | Description |
|---|---|---|
| slug | No | |
| total | No | |
| reviews | No | |
| monitors | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, assuring safe, read-only behavior. The description adds value by detailing the returned data (reviews, state per store) and automatic collection process, without contradicting 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 two sentences, concise and front-loaded with the core purpose. Every sentence is informative without redundancy, making it efficient for an AI agent to parse.
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 presence of annotations and an output schema, the description provides sufficient context: it explains the data sources, what is returned, and the automatic collection. It could be slightly more explicit about the 'monitoring state' aspect, but overall it is complete for a read-only tool with structured output.
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 does not add extra meaning beyond what the schema provides for 'page' (default 1, 20 per page) and 'startup_slug' (from list_my_startups). No additional parameter context is given.
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 retrieves public reviews from Google Play and App Store, specifying the data included (rating, text, developer response) and that it's automatically collected via app links. It is distinct from sibling tools like 'get_releases' or 'get_waitlist' 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 implies usage for monitoring reviews but does not explicitly state when to use this tool vs alternatives, nor when not to use it. It provides context for review retrieval but lacks clear guidelines on exclusions or prerequisites beyond the required 'startup_slug' parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_waitlistARead-onlyIdempotentInspect
Waitlist summary for your startup: aggregated counters (active, per week/month, ready to test, invited/accepted), answer distribution for the question, recent anonymized answers and campaigns with aggregated statistics. Participants' contact details are not returned.
| Name | Required | Description | Default |
|---|---|---|---|
| startup_slug | Yes | Startup slug (from list_my_startups) |
Output Schema
| Name | Required | Description |
|---|---|---|
| slug | No | |
| stage | No | |
| question | No | |
| waitlist | No | |
| campaigns | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating safe read operation. The description adds value by explicitly stating that contact details are not returned, which is a behavioral constraint beyond annotations. No contradictions.
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 concise, single-sentence but detailed, listing all included content and an exclusion. Front-loaded with the core purpose, no unnecessary 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?
Given the single parameter and existence of an output schema, the description provides sufficient detail about the return content (counters, distributions, campaigns) and an important exclusion (no contact details). It is complete for this tool's complexity.
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 description does not add new meaning beyond the schema's description of startup_slug. The baseline of 3 is appropriate as the description does not elaborate further.
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 that the tool returns a waitlist summary with specific aggregated counters, answer distributions, and recent anonymized data. It distinguishes from sibling tools by focusing solely on waitlist analytics, which is unique among the listed tools.
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 describes what the tool does but provides no explicit guidance on when to use it versus alternatives or when not to use it. The context implies it's for waitlist summary, but no explicit when-to or when-not-to instructions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_categoriesARead-onlyIdempotentInspect
List of available categories (slug and name) for create_startup.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds that it returns 'slug and name', which is useful but not extensive; thus a baseline score of 3 is appropriate.
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, clear sentence that front-loads the essential information. Every word is purposeful with no redundancy.
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 has no parameters and an output schema exists, the description is complete. It clearly states the tool's purpose and output fields, fully informing the agent 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 tool has no parameters (0 params), so baseline is 4. The description adds no parameter-specific information but does indicate what the output contains ('slug and name'), which indirectly helps parameter understanding.
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 categories and specifies it is for use with 'create_startup', effectively distinguishing it from sibling tools like 'update_startup' or 'create_release'.
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 by mentioning 'for create_startup', guiding the agent to use this tool when preparing to create a startup. It does not explicitly list alternatives or when-not-to-use, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_my_startupsARead-onlyIdempotentInspect
List of your startups on BetaFinds (slug, name, status). Updates can only be published for startups with APPROVED status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds minimal behavioral context beyond listing the fields, so it does not significantly enhance transparency beyond 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?
Two concise sentences with no unnecessary words. The first states the purpose, and the second adds a relevant constraint. 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?
Given the tool has no parameters and an output schema, the description is complete. It explains what the tool returns and adds context about the status field, which is sufficient for the agent.
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?
There are no parameters, so the baseline is 4. The description does not need to add parameter semantics, and it does not repeat schema information.
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 the user's startups and specifies the fields returned (slug, name, status). It is a specific verb+resource combination and distinguishes from sibling tools like create_startup or update_startup.
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 adds context that updates require APPROVED status, but does not explicitly state when to use this tool versus alternatives. It implies a use case for checking status before publishing, but lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
publish_updateAInspect
Publish an update (an entry in the «What's new» feed) for your startup. Subscribers receive an email summary within ~10 minutes. body supports Markdown.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Text in Markdown (10–20000 characters) | |
| type | No | Type: RELEASE — new version, UPDATE — improvement, FIX — fix, NEWS — news. Defaults to NEWS. | |
| title | Yes | Update title (3–200 characters) | |
| version | No | Version, if applicable (e.g. 1.4.0) | |
| startup_slug | Yes | Startup slug (from list_my_startups) |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | |
| message | No | |
| publishedAt | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are provided, and the description adds value by noting that 'body supports Markdown' and that 'subscribers receive an email summary within ~10 minutes'. These details go beyond the structured annotations and help the agent understand expected 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?
The description is two sentences, no wasted words, and front-loads the purpose. Every sentence contributes meaningful 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?
Given the output schema exists (as per context signals), the description covers return values implicitly. It includes key details like Markdown support, email timing, and character limits from the schema. It is complete for this type of 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 coverage is 100%, so the baseline is 3. The description mentions Markdown support for body, which is already in the schema description ('Text in Markdown'). No additional semantic value is provided 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 explicitly states the action 'publish', the resource 'update (an entry in the «What's new» feed)', and the scope 'for your startup'. This clearly distinguishes it from sibling tools like 'create_release' or 'announce_launch'.
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 by mentioning the email summary for subscribers, but it does not explicitly state when to use this tool vs alternatives (e.g., for general startup updates vs. releases or launches). However, the context is clear enough for an AI agent to differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_asset_uploadAInspect
Get a one-time link to upload a release file (Windows/Mac/Android/Linux, up to 1 GB). Then upload the file: curl -T ''. After uploading, call complete_asset_upload.
| Name | Required | Description | Default |
|---|---|---|---|
| size | Yes | File size in bytes (exact) | |
| sha256 | No | File SHA-256 (hex, optional) | |
| filename | Yes | File name, e.g. MyApp-1.4.0.dmg | |
| platform | Yes | File platform | |
| release_id | Yes | Release ID from create_release |
Output Schema
| Name | Required | Description |
|---|---|---|
| assetId | No | |
| uploadUrl | No | |
| downloadUrl | No | |
| instructions | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the link is one-time and includes a practical curl command. Annotations (readOnlyHint false, destructiveHint false) are consistent. The description adds useful context beyond annotations, such as the file size limit and the recommended upload method.
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: first states purpose and scope, second gives actionable steps. No redundant information; 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?
Given the presence of an output schema, the description adequately covers the tool's role without explaining return values. It mentions the follow-up step (complete_asset_upload) and file size limits. Could briefly mention error scenarios, but overall sufficient for a straightforward multipart upload process.
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 baseline is 3. The description does not add significant detail about individual parameters beyond the schema (e.g., size, sha256), but it provides overall context that ties parameters to the upload process.
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 purpose: 'Get a one-time link to upload a release file' with explicit platform and size limits. It distinguishes from siblings like 'complete_asset_upload' and 'upload_image' by describing its role in a two-step process.
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 explicit steps: get a link, upload via curl, then call complete_asset_upload. This guides the agent on when to use and what to do next, though it does not explicitly state when not to use this tool (e.g., for images).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_startupAIdempotentInspect
Update an existing startup: app-store links, website, short/full description, tags, category, logo and screenshots. Upload the logo and screenshots first via upload_image and pass the returned URLs (screenshots fully replace the current set; to clear the logo, pass an empty string). Pass only the fields you want to change. See current values via list_my_startups. Note: editing an approved startup sends it back to moderation.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Product website URL | |
| logo | No | Logo URL from upload_image (empty string to clear) | |
| tags | No | Tags (up to 6) | |
| tagline | No | One-line tagline (up to 160 characters) | |
| appStoreUrl | No | App Store page link (iOS) | |
| description | No | Full description (min 50 characters) | |
| screenshots | No | Screenshot URLs from upload_image (up to 5; fully replace the current set) | |
| startup_slug | Yes | Startup slug (from list_my_startups) | |
| category_slug | No | Category slug (see list_categories) | |
| googlePlayUrl | No | Google Play page link (Android) | |
| testflightUrl | No | TestFlight link (iOS beta) | |
| prelaunch_ready | No | What is already done: prototype, design, private beta… (up to 1000 characters) | |
| prelaunch_promise | No | What a waitlist subscriber will get (up to 1000 characters) | |
| prelaunch_audience | No | Who the product is for (up to 1000 characters) | |
| target_launch_date | No | Estimated launch date in YYYY-MM-DD format (for prelaunch; empty string clears it) |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | No | |
| slug | No | |
| status | No | |
| message | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses critical behaviors beyond annotations: screenshots fully replace the set, empty clears logo, editing approved startup sends to moderation. Annotations only hint idempotent and non-destructive.
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 front-loading purpose, then bullet-like listing, followed by critical notes. No fluff, 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?
Complete coverage for a complex tool with 15 parameters: explains prerequisites, side effects, and references related tools. Output schema exists so return values need not be detailed.
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 description adds value by explaining relationships (logo/screenshots come from upload_image), replacement semantics, and optionality details.
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 'Update an existing startup' and enumerates the specific fields that can be modified, distinguishing it from sibling tools like create_startup and list_my_startups.
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 explicit guidance: pass only changed fields, upload media first via upload_image, see current values via list_my_startups, and notes moderation effect. Lacks explicit when-not-to-use but is clear overall.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
upload_imageAInspect
Upload an image (logo or screenshot) for create_startup. Pass the file content as base64 (data is base64 only, no data: prefix). Returns a url to pass into create_startup. Max 2 MB; formats: JPEG, PNG, WebP, GIF.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | File content in base64 | |
| filename | No | File name (optional) | |
| mime_type | Yes | MIME type: image/png, image/jpeg, image/webp, image/gif |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | No | |
| path | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals important behavioral details: max 2 MB, allowed formats (JPEG, PNG, WebP, GIF), base64 format without data: prefix, and that it returns a URL. Since annotations provide no such details, the description fully covers behavioral transparency.
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 concise with only essential information front-loaded. Each sentence serves a purpose: purpose, data format, output, and constraints.
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 simplicity and presence of output schema, the description covers purpose, input requirements, constraints, and output usage. It is complete for an AI agent to use 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 baseline is 3. The description adds specific format instructions (no data: prefix) and constraints (max size, formats), providing 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 clearly states it uploads an image (logo or screenshot) for use with create_startup, distinguishing it from sibling tools like request_asset_upload and complete_asset_upload.
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 the tool is for preparing an image for create_startup, providing clear usage context. However, it does not mention when not to use it or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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.
Discussions
No comments yet. Be the first to start the discussion!