Skip to main content
Glama

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 (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.

Input Schema

NameRequiredDescriptionDefault
refNoOptional branch, tag, or commit SHA to pull. Defaults to the latest commit on your stored branch.
bumpNoVersion 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.
repoNoAction 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.
slugYesYour 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

NameRequiredDescriptionDefault
kindNo
slugNo
statusNo
changedNo
versionNo
changelogNo
scan_statusNo
instructionsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • 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."
  2. Changed2 schema fields changed
    • 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."
  3. Changed1 schema field changed
    • 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)."
  4. Changed1 schema field changed
    • 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."
  5. Changed1 schema field changed
    • 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"
      +}
  6. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With annotations only giving readOnlyHint=false/destructiveHint=false/openWorldHint=true, the description adds substantial context the agent cannot infer: owner-only, repo pinned to the prior import, no arbitrary-repo ingest, live version keeps serving until approval (never auto-unpublished), unchanged source is a no-op, and the new version enters admin review with an auto-drafted changelog.

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?

Purpose and core behavior are front-loaded, and the bulk is high-density edge-case handling. It is long, and the trailing 'which tool for which part' survey strays into cross-tool routing that is only marginally in scope, but most sentences carry unique operational 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?

An output schema exists so return values need not be explained, and the description nonetheless covers the tricky cases an agent would otherwise miss: uploaded skills agents, action-agent repo naming, version-number ownership, and the review/no-op semantics. Nothing needed to invoke it correctly 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 coverage is 100%, so the baseline is 3, but the description adds real semantics beyond the schema: it clarifies the `bump` version is derived from the LISTING's version line rather than any repo-declared version, that `repo` applies only to kind mcp-tool agents, and that `ref` defaults to the stored branch's latest commit.

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 opening clause names a specific verb (publish), resource (a new version of YOUR OWN published agent), and mechanism (re-pulling your OAuth-connected GitHub repo). It immediately distinguishes itself from siblings like findagent_bump_version and findagent_reintrospect_mcp by naming exactly which source it re-reads.

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?

It explicitly routes the agent: fields-edited agents go to findagent_bump_version, MCP servers to findagent_reintrospect_mcp, uploaded skills agents to findagent_reupload, and creation flows to create_code_draft/create_package_draft/etc. It also states the when-not case (uploaded source answers `uploaded_source`, cannot be re-pulled).

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