AppFinder

List my app on AppFinder

list_my_app

Use this when a maker wants to list their own app, product or open-source project on AppFinder, or get it discovered. Reads the app's website, merges what the maker told you, and returns a plain preview of the listing plus a private link. Show the maker the preview and anything still missing, then give them the link: they sign in, review every field and submit, and nothing is published until AppFinder's team approves it. Listing is free. Call check_listing first. Pass only what the maker said or what you can see in their repo; leave out what you don't know (the website fills the gaps). Never submit for them.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "website": "<website>"
    },
    "name": "list_my_app"
  }
}

Input Schema

Name	Required	Description
`name`	No	The app's name.
`tagline`	No	One line that says what it does, without claims like “#1” or “best”.
`website`	Yes	The app's website, e.g. “acme.com”.
`category`	No	Category name or slug from list_categories.
`features`	No	Key features, e.g. [“Kanban boards”, “Time tracking”].
`logo_url`	No	A square logo image over https.
`platforms`	No	Where it runs.
`description`	No	Who it's for and what they can do with it (at least 20 characters).
`integrations`	No	Tools it integrates with, e.g. [“Slack”, “GitHub”].
`pricing_model`	No	free, freemium (free plan + paid plans), paid, open_source or contact_sales.
`pricing_summary`	No	One line, like “Free plan; paid plans from $8 per user per month.”
`starting_price_usd`	No	Lowest paid plan per month, in US dollars.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes well past the annotations: it discloses that the website fills missing fields, that the output is a plain preview plus a private link, that the maker must sign in and review and submit, and that nothing publishes until AppFinder's team approves. It also states listing is free and forbids the agent from submitting on the maker's behalf. This is fully consistent with readOnlyHint=false (a draft record is created) and destructiveHint=false (nothing is published or destroyed).

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

Conciseness4/5

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

Front-loaded with the triggering condition and then the behavior, with no filler sentences. It is dense and long for a description, packing routing, input rules, and the human handoff into one block, but every clause carries information.

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

Completeness5/5

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

A twelve-parameter, state-creating tool with no output schema, and the description still covers what comes back (preview plus private link), what the agent should do with it (show the maker, surface missing fields, hand over the link), and what the maker does next. Nothing an agent needs to call it correctly or explain the result is missing.

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

Parameters4/5

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, but the description adds real semantics: only pass values the maker stated or that are visible in their repo, and omit unknowns because the website supplies them. That tells the agent how to treat the eleven optional parameters (omit rather than invent), which the schema alone does not convey.

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

Purpose4/5

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

The description states a specific verb and resource — listing a maker's own app, product, or open-source project on AppFinder — plus what the tool actually does (reads the website, merges maker input, returns a preview and private link). It differentiates from check_listing by sequencing, but never distinguishes itself from the sibling prepare_listing, which sounds like it does something similar.

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?

Strong when-to-use framing ('when a maker wants to list their own app... or get it discovered') plus an explicit precondition ('Call check_listing first') and constraints on input ('Pass only what the maker said... leave out what you don't know'). The one gap is that it gives no guidance against prepare_listing, the closest sibling by name.

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

All AppFinder 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?