FindAgent

findagent_create_package_draft

Create a DRAFT agent from an Agent Plugins package you wrote in this conversation: pass files as an object mapping each path to its TEXT (for example "skills/my-skill/SKILL.md", "skills/my-skill/references/guide.md", ".claude-plugin/plugin.json", "commands/review.md", "agents/reviewer.md"). FindAgent imports it exactly like an uploaded package — the same skill rules (at most 40 skills, valid Agent Skills names; too many is refused, never cut), the same caps (4 MB of text in total, 2 MB per file, 4000 files; the whole request, JSON escaping included, must also stay under the hosting platform's ~4.5 MB request limit), actions only where plugin.json declares them — stores it in your own namespace and saves a status=draft skills agent you own. Binary files cannot be sent. You must pass attestation: "own-work", confirming these are your own files. Then Submit it with findagent_submit_for_review: agent (the draft slug), confirm_original: true, confirm_not_prohibited: true, llms (at least one) and price_type/price_cents. The first call without confirm_slug returns the permanent slug; call again with confirm_slug set to that exact slug to submit. The package is scanned and a person reviews it before anything is published. Instead of files you may pass repo (owner/repo or a github.com URL) and optionally ref and path (the folder of a repository that holds several packages): FindAgent then reads the package from a GitHub repository YOU OWN (it proves you have push access first; connect GitHub with findagent_connect_github if needed), and no attestation is needed because the ownership is proven. Pass exactly one of files or repo. An agent made from a repository is updated by re-pulling it (findagent_repull). Listing fields are the same as findagent_create_draft (title, slug, tagline, description, category); the instructions, prompts and actions come from the files. NEVER put secret values in any file: an action's credentials are declared by name only. Which tool for which part: Instructions, Skills and Actions are authored as an Agent Plugins package and sent as files with findagent_create_package_draft; Code (a Node or Python program) uses findagent_create_code_draft from your own GitHub repo; an MCP server you already run uses findagent_create_remote_mcp (hosted over https) or findagent_create_local_mcp (started on the buyer machine by a command); an OpenAPI spec becomes tools through findagent_import_openapi before findagent_create_draft; findagent_create_draft saves a declarative listing from findagent_import_repo grounding. Code part: start from https://github.com/FindAgent/agent-template (Node and Python variants). Building any part with an assistant: provider-neutral playbooks at https://github.com/FindAgent/agent-creators (start with AGENTS.md).

Input Schema

Name	Required	Description
`ref`	No	With `repo`: a branch, tag or commit SHA. Defaults to the default branch.
`llms`	No
`path`	No	With `repo`: the folder of the repository that IS the package, for a repository that holds several (for example "plugins/pdf"). Only that folder is read. Defaults to the repository root.
`repo`	No	Instead of `files`: a GitHub repository you own (owner/repo or a github.com URL) that holds the package. Its push access is verified before anything is read.
`slug`	Yes	Permanent kebab-case slug (3-60 chars). Check it with findagent_check_slug first.
`tags`	No
`files`	No	The package: each key is a relative file path, each value the full text of that file. At least one SKILL.md (for example "skills/<name>/SKILL.md" with name + description frontmatter).
`title`	Yes	Listing title (3-80 chars).
`tagline`	Yes	One-line value proposition (10-140 chars).
`languages`	No
`attestation`	No	Required with `files`: "own-work" — you confirm these files are your own work (or yours to publish). Not needed with `repo`.
`description`	Yes	Listing description (50-4000 chars).
`tech_domains`	No
`category_slug`	No	Primary category slug (see findagent_list_categories).
`example_prompts`	No	Optional: up to 5 example prompts (more is refused, not cut). Omitted = the ones the package produced.
`additional_category_slugs`	No

Output Schema

Name	Required	Description
`kind`	No
`slug`	No
`title`	No
`status`	No
`account`	No
`created`	No
`left_out`	No
`next_tool`	No
`price_type`	No
`preview_url`	No
`skill_count`	No
`skill_notes`	No
`action_count`	No
`instructions`	No
`category_slug`	No
`left_out_total`	No
`left_out_detail`	No	The summary this field held before left_out became an array: binary file names and their total, the entries the reader set aside and their total.
`slug_is_permanent_after_publish`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 29, 2026

addedOutput schema / properties / left_out / items

Added value: +{
+  "properties": {
+    "path": {
+      "type": "string"
+    },
+    "reason": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

changedOutput schema / properties / left_out / type
```
Previous value: -"object"New value: +"array"
```

addedOutput schema / properties / left_out_detail

Added value: +{
+  "description": "The summary this field held before left_out became an array: binary file names and their total, the entries the reader set aside and their total.",
+  "type": "object"
+}

addedOutput schema / properties / left_out_total
```
Added value: +{
+  "type": "integer"
+}
```

Changed5 schema fields changedOct 13, 2026

changedInput schema / properties / attestation / description

Previous value: -"Required: \"own-work\" — you confirm these files are your own work (or yours to publish)."New value: +"Required with `files`: \"own-work\" — you confirm these files are your own work (or yours to publish). Not needed with `repo`."

addedInput schema / properties / path

Added value: +{
+  "description": "With `repo`: the folder of the repository that IS the package, for a repository that holds several (for example \"plugins/pdf\"). Only that folder is read. Defaults to the repository root.",
+  "type": "string"
+}

addedInput schema / properties / ref

Added value: +{
+  "description": "With `repo`: a branch, tag or commit SHA. Defaults to the default branch.",
+  "type": "string"
+}

addedInput schema / properties / repo

Added value: +{
+  "description": "Instead of `files`: a GitHub repository you own (owner/repo or a github.com URL) that holds the package. Its push access is verified before anything is read.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "files",
-  "attestation",
-  "title",
-  "slug",
-  "tagline",
-  "description"
-]New value: +[
+  "title",
+  "slug",
+  "tagline",
+  "description"
+]

AddedSep 28, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: the result is a private, status=draft agent in your namespace, it is scanned and human-reviewed before publication, output caps are enumerated (40 skills, 4 MB text total, 2 MB/file, 4000 files, ~4.5 MB request limit), over-limit inputs are refused rather than truncated, binaries are rejected, and repo mode requires proven push access. The warning never to put secrets in files is real safety context the annotations do not carry.

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

Conciseness3/5

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

The core is front-loaded and dense with decision-relevant constraints, but the description runs long and the closing block (agent-template repo links, agent-creators playbooks, 'Code part: start from...') belongs to sibling tools rather than this one. A meaningful fraction of the text does not earn its place here.

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?

For a 16-parameter mutation with an output schema and safety annotations, this covers nearly everything an agent needs. It is slightly muddied by blending the submit flow's fields (confirm_slug, price_type/price_cents) and `llms` into this tool's narrative, which can blur which parameters belong to this call versus the follow-up call.

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?

At 69% schema coverage the description meaningfully extends the schema: it explains `files` as a path→text map with example paths, that attestation='own-work' is required only for files mode, that `repo`/`ref`/`path` are read-only-from-GitHub alternatives, and that the first submit call yields the permanent slug. Minor gap: listing-side params (tags, languages, tech_domains, llms, category_slug) are only partially or ambiguously explained.

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?

Opens with a specific verb+resource+scope: 'Create a DRAFT agent from an Agent Plugins package you wrote in this conversation.' It also explicitly distinguishes itself from the sibling draft-creation tools (create_code_draft, create_remote_mcp, create_local_mcp, create_draft), so an agent can pick it without opening schemas.

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

Usage Guidelines5/5

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

Gives explicit when-to-use routing: packages of instructions/skills/actions go here, code goes to create_code_draft, hosted MCP to create_remote_mcp, local MCP to create_local_mcp, OpenAPI to import_openapi. It also names the mandatory next step (findagent_submit_for_review) with the exact fields, and the mutual exclusion of `files` vs `repo`.

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

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?