BotFriendly

submit_service

Submit a service to the BotFriendly directory. There is no review queue: each interface URL must be on the service's own domain and is fetched during the call, and the listing publishes immediately if one answers. Every listing needs an icon — pass icon_url, or leave it out and the service's own site is checked for one.

Input Schema

TableJSON Schema

Name	Required	Description
`url`	Yes	Service URL
`name`	Yes	Service name
`tags`	No
`category`	Yes	Category id (see list_categories)
`icon_url`	No	Link to the service's icon (PNG, JPEG, SVG or WebP, under 1MB). Fetched and re-hosted, downscaled to 512px. Omit it and the service's site is checked for one.
`accepts_mpp`	No
`auth_method`	No	Auth method
`description`	Yes	Short description (max 120 chars)
`icon_base64`	No	Alternative to icon_url: the image inline, as a data: URI or bare base64.
`accepts_x402`	No
`billing_model`	No
`contact_email`	No	Contact email for verification
`has_mcp_server`	No
`mcp_server_url`	No	Required when has_mcp_server is true, and must be on the service's own domain.
`has_openapi_spec`	No
`openapi_spec_url`	No	Required when has_openapi_spec is true, and must be on the service's own domain.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 18, 2026

changedInput schema / properties / category / description

Previous value: -"Category slug"New value: +"Category id (see list_categories)"

addedInput schema / properties / category / enum

Added value: +[
+  "think",
+  "see",
+  "hear-speak",
+  "create",
+  "remember",
+  "search",
+  "browse",
+  "communicate",
+  "execute",
+  "pay",
+  "shop",
+  "markets",
+  "platforms",
+  "identify",
+  "monitor",
+  "other",
+  "locate",
+  "book",
+  "hire",
+  "sign",
+  "trade",
+  "bet",
+  "connect",
+  "automate"
+]

First observedSep 1, 2026

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states that there is no review queue, the listing publishes immediately, the interface URL is fetched during the call, and the icon can be omitted with a fallback to the site. This is substantial behavioral detail, though it does not cover failure modes or permission requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two dense sentences with no filler. It front-loads the core action, then efficiently presents the critical caveats about review, domain verification, and icon requirements. Every clause adds operational value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 16 parameters, 63% schema coverage, and no output schema, the description delivers the essential behavioral contract needed to call the tool correctly: domain constraint, immediate publication, and icon fallback. It could say more about what is returned or what happens on validation failure, but the description is reasonably complete for a submission tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 63%, and the schema already documents most parameter meanings. The description adds meaningful semantics for icon handling ('Every listing needs an icon — pass icon_url, or leave it out and the service's own site is checked for one') and for URL domain requirements. However, many optional parameters such as auth_method, billing_model, and accepts_mpp remain only minimally described in the schema with no added context from the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Submit a service to the BotFriendly directory.' It also clarifies the unique submission behavior ('listing publishes immediately'), which distinguishes it from the read-only sibling tools. There is no ambiguity about what operation this tool performs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear operational context: no review queue, the URL must be on the service's own domain, the interface is fetched during the call, and every listing needs an icon. It does not explicitly contrast with sibling tools, but all siblings are query/read tools whereas this is the only submission tool, so the intended usage is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All BotFriendly tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?