FindAgent

findagent_import_repo

Read-only

Pull the CALLER'S OWN GitHub repo (via their connected token) and return deterministic grounding (basics, languages, tech domains, detected tools + the hosts they reach, and what the repo IS — skills, actions, runnable code or instructions only — with the parts found) plus a field contract. Use the grounding as the basis, then run findagent_submission_wizard to walk the user through the listing step-by-step and finalize with findagent_create_draft — your own model does the synthesis (no FindAgent LLM cost). Pass path for a repository that holds several packages (only that folder is read). Files the reader had to leave out are listed in left_out. Read-only: nothing is persisted or executed. Works for PRIVATE repos: the pull runs server-side with your stored GitHub token, so your AI client never needs repo access.

Input Schema

Name	Required	Description
`ref`	No	Optional branch/tag/SHA. Defaults to the default branch HEAD.
`path`	No	Optional 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`	Yes	owner/repo or a github.com URL (must be readable by your connected GitHub token). Private repos you own work — the pull is server-side.

Output Schema

Name	Required	Description	Default
`path`	No
`repo`	No
`commit`	No
`left_out`	No
`grounding`	No
`instructions`	No
`field_contract`	No
`already_imported`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 29, 2026

addedInput schema / properties / path

Added value: +{
+  "description": "Optional 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"
+}

addedOutput schema / properties / left_out

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

addedOutput schema / properties / path
```
Added value: +{
+  "type": "string"
+}
```

Changed1 schema field changedOct 1, 2026
- changedOutput schema / properties / grounding / properties / code_bundle / properties / confidence / type
```
Previous value: -[
-  "number",
-  "string",
-  "null"
-]New value: +[
+  "object",
+  "number",
+  "string",
+  "null"
+]
```
Changed2 schema fields changedSep 26, 2026
- addedOutput schema / properties / grounding / properties / detected_components
```
Added value: +{
+  "type": "object"
+}
```
- addedOutput schema / properties / grounding / properties / detected_warnings
```
Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
```
First observedSep 1, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only say readOnlyHint/openWorldHint; the description adds substantive context beyond that: nothing is persisted or executed, private repos work because the pull runs server-side with the stored GitHub token, the client never needs repo access, excluded files surface in `left_out`, and synthesis happens in the caller's model with no FindAgent LLM cost. These are behavioral traits an agent could not infer from annotations or schema.

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?

Front-loaded: the action and the returned grounding come first, followed by workflow routing, then caveats. It is dense to the point of being a single sprawling sentence with nested parentheticals, which costs a little readability, but essentially every clause carries useful 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 only be gestured at, yet the description characterizes the grounding and the field contract, covers the private-repo auth story, the monorepo case, and the truncation signal (`left_out`). Nothing an agent needs to call it correctly is missing.

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

Parameters3/5

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

Schema coverage is 100%, so all three parameters including `ref` and `repo` are already documented in the schema. The description's note about `path` (only that folder is read) largely restates the schema's own wording, and it never mentions `ref`. Baseline 3 is appropriate when the schema carries the parameter burden.

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?

States a specific verb and resource ('Pull the CALLER'S OWN GitHub repo ... and return deterministic grounding') and enumerates exactly what the grounding contains (basics, languages, tech domains, detected tools + hosts, what the repo IS). This is distinguishable from siblings like findagent_repull or findagent_list_repos because it names the token-backed pull and the grounding payload.

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?

Explicitly sequences the workflow: use the grounding as the basis, then run findagent_submission_wizard, then finalize with findagent_create_draft. It also names the condition for `path` (repo holding several packages) and states the pull is read-only, so an agent knows when this is and is not the right entry point.

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?