FindAgent

findagent_bump_version

Publish a NEW version of YOUR OWN published doer/declarative agent for review. Pass the agent slug + a semver bump (patch|minor|major). You can fully EDIT the new version: system_prompt + example_prompts, AND (for a doer/recipe) the whole capability surface — pass tools (and optional credential_slots / guardrails) to add/remove/edit tools + action bindings + credential slots, and optional price_type/price_cents to change the price. Any capability change re-runs the same security scan + author-time auth_ref↔host check. changelog is optional when you edit tools (auto-drafted from the diff); otherwise pass 10–500 chars. The new version goes to admin review; your LIVE version keeps serving until it is approved (never auto-unpublished). A price change applies immediately (not retroactive). Owner-only. (Code-bundle agents re-version through the code wizard, not here.)

Input Schema

TableJSON Schema

Name	Required	Description
`bump`	Yes
`llms`	No	Target clients ⊂ {claude,chatgpt,gemini,cursor,vscode,custom}.
`slug`	Yes	Your published agent slug (you must own it).
`tools`	No	Optional FULL doer tool set for the new version (web-builder parity). Presence REPLACES the agent's whole tool surface — pass the complete intended list (add/remove/edit); item shape is in `items`. auth_ref must match a credential_slots[].ref whose allowed_hosts cover the action host (audience binding — enforced). Omit to keep the stored tools (prompt-only edit).
`changelog`	No	What changed (10–500 chars). Optional when you pass `tools` — then it is auto-drafted from the tool diff; supply your own to override.
`guardrails`	No	Optional declared guardrails for the new version (you can only TIGHTEN; the platform always applies its mandatory rails). An invalid block fails the bump.
`price_type`	No	Optional. Change the price alongside the bump. Applies immediately (audited, not retroactive — existing buyers keep access).
`price_cents`	No	Required when price_type=paid: positive integer of US cents, max 50000 ($500).
`system_prompt`	No	The updated agent instructions. For a doer whose prompt isn't the authoring surface (mcp-tool / skills-bundle) you may omit it to keep the stored one; otherwise min 50 chars.
`example_prompts`	No	Up to 5 concrete things a user can ask it to do.
`credential_slots`	No	Optional. The new version’s full credential-slot set when you pass `tools` — item shape is in `items`. DEFINITIONS ONLY — never send secret VALUES.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`slug`	No
`status`	No
`version`	No
`changelog`	No
`instructions`	No

TDQS

A4.7/5.0

Behavior5/5

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

The description adds significant behavioral context beyond the sparse annotations: the new version 'goes to admin review', the live version 'keeps serving until it is approved (never auto-unpublished)', capability changes 're-run the same security scan + auth_ref↔host check', and a price change 'applies immediately (not retroactive)'. It also warns that passing `tools` 'REPLACES the agent's whole tool surface'.

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?

The description is dense and front-loaded with the primary action, and every sentence carries operational constraints (review flow, price immediacy, owner-only, code-bundle exclusion). It is long and run-on, but the information density justifies the length.

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?

For an 11-parameter mutation tool with nested objects, the description covers the approval lifecycle, security re-scan, auth binding requirements, tool-surface replacement semantics, pricing behavior, and owner authorization. Combined with the high schema coverage and output schema, an agent has everything needed to invoke it correctly.

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

Parameters5/5

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

With 91% schema coverage the schema already documents most parameters, and the description still adds meaning: `bump` is a semver patch/minor/major, `tools` means a full replacement rather than a delta, `changelog` is auto-drafted when tools change, and `credential_slots` are 'DEFINITIONS ONLY — never send secret VALUES'. This substantially helps an agent construct a correct call.

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 — 'Publish a NEW version of YOUR OWN published doer/declarative agent for review' — and immediately identifies the actor ('YOUR OWN', 'Owner-only') and the semver bump. It also distinguishes itself from siblings by explicitly excluding code-bundle agents ('re-version through the code wizard, not here').

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?

It states clear context for use: publishing a new version, editing prompt/tools, and triggering re-review, and it gives one explicit exclusion (code-bundle agents use the code wizard). It does not enumerate alternative tools such as findagent_edit_price or findagent_rollback_version, so the when-not guidance is partial rather than exhaustive.

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

All FindAgent tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0

Disambiguation5/5

Every tool targets a clearly scoped resource+action combination, and the versioning variants (bump_version vs repull vs reintrospect_mcp) are explicitly disambiguated by agent kind. Even with 52 tools, the descriptions make each purpose distinct enough to avoid misselection.

Naming Consistency4/5

Nearly all tools follow the findagent_<verb>_<object> snake_case pattern, and families share predictable verbs like list, create, delete, edit, and submit. Minor exceptions such as findagent_preflight, findagent_whoami, and findagent_earnings keep it from perfect consistency.

Tool Count2/5

At 52 tools, this far exceeds the 25-tool threshold for a coherent MCP surface. The count may reflect a broad platform, but as a single toolset it is heavy and likely to strain agent selection and context.

Completeness3/5

The surface covers publishing, versioning, knowledge bases, org management, GitHub import, purchases, and the demand board in impressive depth. However, there are notable dead ends: no unpublish/delete for a live agent, no request-fulfillment/linking action, and no org deletion or KB document update.

Resources

Need Help?