Skip to main content
Glama

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 call findagent_submit_for_review in this client (price, originality and prohibited-content confirmations): the package is scanned and a person reviews it before anything is published. 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; 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

TableJSON Schema
NameRequiredDescriptionDefault
llmsNo
slugYesPermanent kebab-case slug (3-60 chars). Check it with findagent_check_slug first.
tagsNo
filesYesThe 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).
titleYesListing title (3-80 chars).
taglineYesOne-line value proposition (10-140 chars).
languagesNo
attestationYesRequired: "own-work" — you confirm these files are your own work (or yours to publish).
descriptionYesListing description (50-4000 chars).
tech_domainsNo
category_slugNoPrimary category slug (see findagent_list_categories).
example_promptsNoOptional: up to 5 example prompts (more is refused, not cut). Omitted = the ones the package produced.
additional_category_slugsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNo
slugNo
titleNo
statusNo
accountNo
createdNo
left_outNo
next_toolNo
price_typeNo
preview_urlNo
skill_countNo
skill_notesNo
action_countNo
instructionsNo
category_slugNo
slug_is_permanent_after_publishNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior4/5

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

With only readOnlyHint=false/destructiveHint=false in annotations, the description carries the burden well: it discloses the skill cap (40, 'refused, never cut'), size caps (4 MB total, 2 MB per file, 4000 files, ~4.5 MB request), that binary files cannot be sent, that the package is stored in the caller's namespace as a status=draft listing, and that a human reviews before publication. It stops short of stating auth/permission requirements or what a partial failure returns, but this is unusually rich disclosure.

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 action is front-loaded in the first sentence, but the body is a single dense run-on paragraph mixing limits, workflow rules, tool-selection routing, and external template URLs. The trailing repository links (agent-template, agent-creators) are tangential to invoking this tool and dilute the payload.

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 a 13-parameter, nested-object, write-operation tool, the description covers the input format, all hard limits, the attestation requirement, the draft state and ownership outcome, and the mandatory review step. Return values are not needed since an output schema exists.

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 coverage is 62%, and the description compensates for the gap: it explains the `files` object shape (path -> full TEXT) with concrete example paths including plugin.json and commands/*.md, clarifies that listing fields come from the same source as findagent_create_draft while instructions/prompts/actions come from files, and reinforces the attestation enum value. It does not cover every listing metadata parameter (llms, tech_domains, tags), leaving some schema reliance.

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: 'Create a DRAFT agent from an Agent Plugins package you wrote in this conversation.' It immediately distinguishes itself from the near-identically named siblings by naming them and the exact part each covers ('Instructions, Skills and Actions ... findagent_create_package_draft; Code ... findagent_create_code_draft; an MCP server ... findagent_create_remote_mcp').

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?

Includes an explicit 'Which tool for which part' decision table mapping each authoring input to the correct tool, states the required follow-up call (findagent_submit_for_review) and why, and notes the prerequisite attestation. An agent can select this tool vs its siblings without inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources