FindAgent

findagent_list_my_agents

Read-only

List the agents that are YOURS, in either sense. scope:"created" (the default) returns agents you CREATED — id + slug + name + kind + status + any in-flight re-version status — plus your personal departments; call it FIRST when you need a slug for a lifecycle tool (findagent_edit_price / findagent_bump_version / findagent_withdraw_version / findagent_edit_metadata / findagent_rollback_version), to submit a draft (findagent_submit_for_review — a draft/needs_changes agent is submittable), or to attach a knowledge base (findagent_attach_kb). scope:"acquired" returns agents you BOUGHT or INSTALLED — your library — which is what to call when a buyer asks what they have access to; those are not yours to edit. An acquired row carries update_awaiting_your_approval:true when a newer version asks for more permissions than were accepted and the buyer has not approved it yet, so they are still being served the earlier version (approval is given on the agent page). scope:"all" returns both. Essential after reconnecting in a new session, when you no longer have the slug of something you created or acquired earlier. READ-ONLY.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`scope`	No	Which sense of "mine": created (default — agents you authored, editable via the lifecycle tools), acquired (agents you bought or installed, read-only to you), or all.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`agents`	No
`acquired`	No
`departments`	No
`instructions`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 11, 2026

addedInput schema / properties / scope

Added value: +{
+  "description": "Which sense of \"mine\": created (default — agents you authored, editable via the lifecycle tools), acquired (agents you bought or installed, read-only to you), or all.",
+  "enum": [
+    "created",
+    "acquired",
+    "all"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / acquired

Added value: +{
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

First observedSep 1, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations cover read-only safety, but the description goes beyond: it discloses editability semantics (created=editable, acquired=read-only to you), the update_awaiting_your_approval state and its consequence (still served the earlier version), and where approval is given (the agent page). This is rich behavioral context not derivable from the annotations.

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 content is front-loaded with the scope semantics, but the prose is dense and sprawling with many parenthetical tool references and asides. It is longer than needed for a single-parameter list tool; some clauses (e.g. listing five lifecycle tool names) could be trimmed.

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 an output schema exists and annotations carry read-only safety, the description still supplies the session-reconnection use case, scope semantics, and the acquired approval-state behavior. Nothing needed to invoke or route 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 description coverage is 100% and the enum is fully documented in the schema, so the schema does the heavy lifting. The description adds some meaning by mapping each scope to ownership sense and editability, which is contextual value but largely restates the enum semantics.

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 description states a specific verb and resource ('List the agents that are YOURS'), distinguishes two ownership senses via the scope parameter, and names the downstream lifecycle tools by slug. An agent can tell it apart from siblings like browse_agents or get_agent without opening the schema.

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?

Explicit when-to-use for each scope: 'call it FIRST when you need a slug for a lifecycle tool...', acquired is 'what to call when a buyer asks what they have access to', and 'Essential after reconnecting in a new session'. It names the exact alternative selection condition and the exclusion ('those are not yours to edit').

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?