FindAgent

findagent_repull

Publish a NEW version of YOUR OWN published agent built from a CODE or SKILLS repo by RE-PULLING your OAuth-connected GitHub repo. FindAgent re-fetches your repo (at an optional branch/tag/commit ref, default = the latest commit on your stored branch), re-snapshots + re-scans it (a code bundle also re-builds), diffs it against your live version, and — if it CHANGED — submits a new version for admin review with an auto-drafted changelog. Your LIVE version keeps serving until the new one is approved (never auto-unpublished). If the source is unchanged it is a no-op. Pass the agent slug (you must own it) + optional ref. Owner-only; the repo is pinned to your agent's own prior import (arbitrary-repo ingest is not available here). VERSION NUMBER: the new version is computed from the LISTING's current version plus bump, NOT from any version in your repo (package.json / manifest) — the listing owns its own version line, so hand-editing a version in the repo does not change what gets published here, and the two can legitimately differ. For agents built from a repo: a code or skills agent re-pulls the repo it was imported from, and an ACTION agent (kind mcp-tool) re-pulls the repo you NAME with repo (owner/name, one you can write to) — its findagent.json is read server side, so its whole tool array never passes through a model; the actions pass the same annotation floor and credential-host binding as every other door and the new version enters review. An agent whose fields you edit directly re-versions via findagent_bump_version, an MCP server via findagent_reintrospect_mcp. A skills agent that was UPLOADED (no GitHub repo) cannot be re-pulled: it answers uploaded_source, and its next version is uploaded instead — with findagent_reupload, or on the web dashboard. 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.

Input Schema

TableJSON Schema

Name	Required	Description
`ref`	No	Optional branch, tag, or commit SHA to pull. Defaults to the latest commit on your stored branch.
`bump`	No	Version bump for this re-version — patch (default), minor (a feature release, e.g. 0.1.x → 0.2.0), or major. Omit for patch. Applied to the LISTING's current version, not to any version declared in the repo.
`repo`	No	Action agents (kind mcp-tool) only: the GitHub repo to read, owner/name or a github.com URL, one you can write to. Its findagent.json (or a manifest.json declaring schema_version 1.1) supplies the tool surface. Ignored for code and skills agents, which re-pull the repo they were imported from.
`slug`	Yes	Your published agent slug, built from a repo (you must own it): a code or skills agent, or an action agent when you also pass repo.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`kind`	No
`slug`	No
`status`	No
`changed`	No
`version`	No
`changelog`	No
`scan_status`	No
`instructions`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 2, 2026

changedInput schema / properties / repo / description

Previous value: -"Action agents (kind mcp-tool) only: the GitHub repo to read, owner/name or a github.com URL, one you can write to. Its findagent.json supplies the tool surface. Ignored for code and skills agents, which re-pull the repo they were imported from."New value: +"Action agents (kind mcp-tool) only: the GitHub repo to read, owner/name or a github.com URL, one you can write to. Its findagent.json (or a manifest.json declaring schema_version 1.1) supplies the tool surface. Ignored for code and skills agents, which re-pull the repo they were imported from."

Changed2 schema fields changedOct 2, 2026

addedInput schema / properties / repo

Added value: +{
+  "description": "Action agents (kind mcp-tool) only: the GitHub repo to read, owner/name or a github.com URL, one you can write to. Its findagent.json supplies the tool surface. Ignored for code and skills agents, which re-pull the repo they were imported from.",
+  "type": "string"
+}

changedInput schema / properties / slug / description

Previous value: -"Your published agent slug, built from a code or skills repo (you must own it)."New value: +"Your published agent slug, built from a repo (you must own it): a code or skills agent, or an action agent when you also pass repo."

Changed1 schema field changedSep 27, 2026

changedInput schema / properties / slug / description

Previous value: -"Your published code-bundle or skills-bundle agent slug (you must own it)."New value: +"Your published agent slug, built from a code or skills repo (you must own it)."

Changed1 schema field changedSep 15, 2026

changedInput schema / properties / bump / description

Previous value: -"Version bump for this re-version — patch (default), minor (a feature release, e.g. 0.1.x → 0.2.0), or major. Omit for patch."New value: +"Version bump for this re-version — patch (default), minor (a feature release, e.g. 0.1.x → 0.2.0), or major. Omit for patch. Applied to the LISTING's current version, not to any version declared in the repo."

Changed1 schema field changedSep 4, 2026

addedInput schema / properties / bump

Added value: +{
+  "description": "Version bump for this re-version — patch (default), minor (a feature release, e.g. 0.1.x → 0.2.0), or major. Omit for patch.",
+  "enum": [
+    "patch",
+    "minor",
+    "major"
+  ],
+  "type": "string"
+}

First observedSep 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds substantial workflow detail beyond that: re-fetching, re-snapshotting, re-scanning, diffing, conditional submission for admin review, live version continues serving, never auto-unpublished, and no-op on unchanged source.

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 purpose is front-loaded and most sentences carry distinct routing or behavioral information. However, the description is quite long and includes a closing sibling-routing list that, while useful, is slightly tangential to the immediate invocation.

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?

Given the complexity of the re-pull workflow, the annotations, and the presence of an output schema, the description covers the necessary behavioral and routing details. An agent can determine when to invoke it, what it does, and what alternatives exist without needing more.

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 100%, so the baseline is 3. The description adds context beyond the schema: it clarifies that the repo is pinned to the agent's prior import, arbitrary-repo ingest is unavailable, and owner-only applies, reinforcing how each parameter must be used.

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 first sentence states a specific verb (publish a new version), resource (your own published agent), and mechanism (re-pulling your OAuth-connected GitHub repo). It distinguishes itself from siblings like findagent_bump_version, findagent_reintrospect_mcp, and findagent_reupload by explaining exactly which cases it covers.

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?

The description explicitly routes the agent: direct field edits use findagent_bump_version, MCP servers use findagent_reintrospect_mcp, uploaded skills agents use findagent_reupload, and the closing list maps authoring paths to findagent_create_* tools. It also states owner-only and repo-pinning constraints.

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?