Search AgentCV's registry of AI agent teams and check a team profile before registering it.
Scored across 6 tools
Each tool has a distinct target: fetch one team, search teams, browse platform hubs, browse use-case hubs, retrieve the registration schema, validate a profile. The only mild adjacency is get_registration_schema vs validate_team_profile (both in the registration flow) and list_platforms vs list_use_cases (two parallel facets of the same taxonomy), but the descriptions make the boundaries clear.
All six tools follow a strict snake_case verb_noun pattern (get_team, list_platforms, list_use_cases, search_teams, validate_team_profile, get_registration_schema). Verbs are used consistently for their intent: get for single-object fetch, list for enumerated hubs, search for filtered queries, validate for checking.
Six tools is well within the sensible range and each earns its place: one search, one detail fetch, two taxonomy browsals, one schema fetch, one validator. There is no redundancy or filler, and nothing suggests a missing wrapper tool.
For a deliberately read-only registry surface it covers discovery (search with filters and cursor pagination), detail (get_team with roster, evidence, sources), taxonomy (platforms, use cases), and the contribute-side path (schema plus validation with finishUrl). Minor gaps: platform/use-case hubs expose only counts with no direct listing or hub-detail tool, so agents must reconstruct those listings via search_teams filters.
The agentcv.team.v1 format for registering a team: the JSON Schema (as an object, and as the exact text agentcv.ai/agentcv-team.schema.json serves) and the self-contained prompt from agentcv.ai/register/with-agent that tells an agent how to write the profile. Registration itself is done by a person on agentcv.ai; this server cannot submit anything. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| format | Yes | |
| prompt | Yes | |
| schema | Yes | |
| schemaUrl | Yes | |
| schemaJson | Yes | |
| howToRegister | Yes | |
| promptPageUrl | Yes | |
| finishRegistrationUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description adds useful behavioral context beyond those annotations: it explains exactly what is returned and clarifies that registration cannot be submitted through this server. It does not discuss caching or rate limits, but the added context is meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the format and return content, then adds the important limitation about registration. It is compact and mostly free of waste, though the final 'Read-only' sentence slightly repeats the readOnlyHint annotation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter schema-retrieval tool with an output schema, the description is complete. It identifies the format, the two representations returned, the prompt source, and the key limitation that the server cannot submit registration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to explain. The baseline for a parameterless tool is 4, and the description does not need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource and return content: the agentcv.team.v1 JSON Schema as an object, the exact schema text, and the registration prompt. It clearly distinguishes this from submission by noting that registration is done by a person and the server cannot submit anything. It does not explicitly differentiate from siblings such as validate_team_profile, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to obtain the format before writing a team profile, and it explicitly says the server cannot submit registration. However, it does not name alternatives or state when to use validate_team_profile versus this schema tool. Usage guidance is therefore present but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The public profile of one AgentCV team, as its page shows it: layer and its notice (curated teams are documented by AgentCV from public sources and are not endorsed by the team), the reference-design label, owner, trust tier, topology, size, roster (name, role and the model where stated), how it is built and overseen, evidence entries with their links and titles, cited sources, and — for an unclaimed curated team — the links where its operator can claim it or ask for its removal. Only public fields. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The team’s slug, as search_teams returns it (e.g. "ari-collective"). |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| name | Yes | |
| size | No | Team size as the site words it: kind "total" is the stated size ("5 agents"); kind "listed" is a curated team whose sources state no total ("3 listed members"). null when no size is stated. |
| slug | Yes | |
| class | Yes | |
| layer | Yes | |
| owner | Yes | |
| trust | Yes | |
| notice | Yes | |
| roster | Yes | |
| status | Yes | |
| sources | Yes | |
| tagline | Yes | |
| claimUrl | Yes | |
| evidence | Yes | |
| platform | No | |
| topology | No | |
| blueprint | Yes | |
| taskKinds | No | |
| industries | No | |
| removalUrl | Yes | |
| requestUrl | No | |
| evidenceTotal | No | |
| operatingSince | No | |
| referenceDesign | Yes | Set when the profile is a reference design: a design documented from a paper, framework docs or vendor material that no one is known to operate. null for every other team. |
| operatingSinceLabel | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that: only public fields are returned, and 'for an unclaimed curated team' it exposes claim/removal links, plus the important caveat that curated teams are documented from public sources and not endorsed. It stops short of describing error behavior or whether a nonexistent slug errors versus returns empty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single, front-loaded sentence with no filler, opening with the purpose before the field inventory. The long enumeration of return fields overlaps with the existing output schema, which is mild redundancy, but it remains readable and wastes little.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 spelled out, and annotations cover the safety semantics; combined with the description's note on public-only fields and claim links, an agent has what it needs to call this correctly. The main omission is any routing guidance relative to search_teams and validate_team_profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the slug parameter already documents format and an example ('ari-collective'), so the schema carries the burden. The description adds no further meaning about the slug beyond identifying that it targets one team; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource and scope: 'The public profile of one AgentCV team,' and enumerates the returned fields (layer, trust tier, topology, roster, evidence entries, sources), so an agent knows exactly what this retrieves. It does not explicitly contrast itself with siblings like search_teams or validate_team_profile, which is why it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: fetch a single team by slug, as referenced indirectly through the schema note 'as search_teams returns it.' There is no explicit when-to-use statement, no guidance on when to prefer search_teams over this lookup, and no mention of what happens for an unknown slug.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The platform hubs of agentcv.ai/platforms (Claude, OpenAI Codex, OpenClaw, CrewAI, LangGraph, …) with the platform names each covers and how many public teams each holds, by layer and by class. AgentCV is independent and not affiliated with any platform. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| platforms | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered and the trailing 'Read-only.' is redundant. The description does add useful behavioral context: this is a curated, fixed catalog of external platform hubs rather than user-generated data, plus an independence disclaimer. It says nothing about result size, ordering, or caching, so the value added is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, resource named first, with the payload described immediately after. The independence/trademark disclaimer is defensible but is the one element that doesn't help an agent decide or invoke; everything else earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A zero-parameter, read-only listing tool with an output schema, so return-format detail is not required. The description covers scope and payload adequately. The only gap is workflow placement relative to search_teams and get_team, which matters because all five siblings operate over adjacent data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the description correctly introduces no parameter discussion. There is no schema surface for the description to explain beyond the grouping dimensions it mentions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the concrete resource (the platform hubs of agentcv.ai/platforms) and enumerates the payload: platform names covered and public team counts, broken down by layer and class. Examples (Claude, OpenAI Codex, OpenClaw, CrewAI, LangGraph) make the scope unmistakable. It stops short of explicitly contrasting itself with siblings like search_teams, which keeps it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no stated relationship to sibling tools such as search_teams or list_use_cases, and no indication that this is a discovery entry point that feeds later filtered queries. The agent must infer the tool's role in a workflow from the resource description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The use-case hubs of agentcv.ai/use-cases (code review, testing and QA, research and analysis, …) with how many public teams each holds, by layer (real, curated, illustrative) and by class (operated, reference design, illustrative). Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| useCases | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the trailing 'Read-only.' sentence adds nothing new. What the description does add beyond the annotations is the shape of the payload (per-hub public-team counts broken down by layer and class), which is genuinely useful context even though an output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence carries the resource, example hubs, and both aggregation dimensions with no filler. The only waste is the redundant 'Read-only.' clause, which repeats the annotation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and a published output schema, the description need only establish what the listing contains, and it does so by naming the layer and class breakdowns. The remaining gap is routing guidance relative to the sibling listing and search tools, which is minor for a simple catalog call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters and the schema accepts no properties, so there is nothing for the description to disambiguate. Baseline for a zero-parameter tool is 4, and nothing in the text misrepresents the calling contract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (the use-case hubs of agentcv.ai/use-cases) and enumerates example values plus the two aggregation dimensions (layer and class) with their possible values. An agent can tell it is a static catalog listing rather than the team-searching sibling tools, though it never explicitly contrasts itself with search_teams or list_platforms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the enumerated hub names and counts suggest this is the entry point for discovering use-case categories before drilling into teams. There is no explicit when-to-use, when-not-to-use, or named alternative among get_team, search_teams, or list_platforms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the public AgentCV registry of AI agent teams. Returns public teams only, in the site’s default order: operated teams first, then reference designs (designs documented from papers, framework docs or vendor material that no one is known to run), then clearly labelled illustrative demos. Each team has its layer (real = registered by its owner, curated = documented by AgentCV from cited public sources, illustrative = demo), size wording, platform, topology, trust tier and page URL. All filters are optional and combine with AND. Pages of up to 20; pass nextCursor back as cursor for the next page. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| layer | No | real = registered by its owner; curated = documented by AgentCV from cited public sources; illustrative = clearly labelled demo. | |
| limit | No | Teams per page, 1–20 (default 10). | |
| query | No | Text to find in a team’s name, tagline or description (case-insensitive substring), as the search box on agentcv.ai/teams. | |
| cursor | No | nextCursor from the previous page; omit for the first page. | |
| platform | No | A platform hub slug (see list_platforms): teams whose own platform or any listed member’s platform belongs to that hub. | |
| topology | No | The team’s declared topology type. | |
| use_case | No | A use-case hub slug (see list_use_cases). |
| Name | Required | Description |
|---|---|---|
| order | Yes | |
| teams | Yes | |
| total | Yes | Teams matching the filters, across all pages. |
| returned | Yes | |
| nextCursor | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotent/non-destructive, so the description's added value is the non-obvious behavior: only public teams are returned, results follow a three-tier default ordering (operated, then reference designs, then illustrative demos), pages cap at 20, and nextCursor must be fed back as cursor. That ordering and page-cap disclosure is exactly the kind of thing structured fields cannot convey, though it stops short of describing rate limits or what an empty result means.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and scope, then ordering, then pagination mechanics, then the AND rule — a sensible sequence. The long parenthetical defining reference designs is slightly heavy but earns its place by preventing an agent from mistaking curated entries for running deployments.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter, fully-described, zero-required search tool with an output schema, everything an agent needs is present: what is searched, what is excluded (non-public), result ordering, page size and cursor protocol, and filter combination logic. Return-value shape is correctly left to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline would be 3, but the description adds genuine cross-parameter semantics the schema cannot express: filters are all optional and are ANDed together, and cursor is the previous page's nextCursor. It also reinforces the layer vocabulary (real/curated/illustrative) in prose terms an agent can reason about when choosing a filter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource ('Search the public AgentCV registry of AI agent teams') and scopes it to public teams only. The sibling set (get_team, list_platforms, list_use_cases) covers single-record and hub-listing operations, and 'Search ... registry' clearly occupies the discovery slot that none of them fill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied rather than stated: 'All filters are optional and combine with AND' plus the cursor instructions tell an agent how to drive the tool, and 'see list_platforms' / 'see list_use_cases' gesture at prerequisites. However, it never says when to reach for this versus get_team (e.g. after obtaining a slug) or when a filter should be preferred over free-text query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check an agentcv.team.v1 team profile with the same validator the registration page’s import panel uses (the same field rules the server enforces), and with AgentCV’s secret and personal-data detectors. Returns the errors, the warnings (example values left in, values over the form’s limit, ignored keys) and the fields that look like an API key, token, password or personal data (named by path, never repeated), plus the URL where a person signs in, imports the file, reviews it and submits. When the profile is ready, it also returns finishUrl: the registration form’s link with the profile in its # fragment, at most 16 KB, for the person to open, review and submit. Browsers do not send the fragment in HTTP requests, but it is not encrypted: anyone with the link can read it. No link is returned while a value, as written or once percent-, base64- or hex-decoded, looks like a secret, personal data, a local path or a private or credential-bearing link; detection is best effort, and the person’s review before Submit is the final check. This server receives the profile to check it; it neither stores nor logs it, and submits nothing. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| profile | Yes | The profile: the agentcv.team.v1 JSON object, or its JSON text exactly as it would be pasted into the import panel (at most 64 KB). |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| errors | Yes | |
| stored | Yes | |
| redacted | Yes | |
| warnings | Yes | |
| withheld | Yes | |
| finishUrl | Yes | |
| nextSteps | Yes | |
| truncated | Yes | |
| finishLink | Yes | |
| readyToImport | Yes | |
| finishRegistrationUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (read-only, idempotent, non-destructive, closed-world), and the description still adds substantial context beyond them: it returns errors, warnings and detected-secret paths, the value is detected after percent/base64/hex decoding, the fragment link is capped at 16 KB and is unencrypted, and the server neither stores nor logs the profile. The best-effort caveat and the 'no submit' statement are exactly the behavioral disclosures an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and the outcome (errors, warnings, detected fields, sign-in URL, finishUrl) are front-loaded, which is good. However, the body is a dense run-on block with visible repetition ('reviews it and submits' appears twice) and several nested caveats crammed into single sentences, making it harder to scan than it needs to be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter validation tool with an output schema, this covers everything an agent needs to decide, call and interpret correctly: what is checked, what is returned, when the link is withheld, and the security properties of the returned fragment. Nothing material is left to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains that the single parameter accepts either the JSON object or its JSON text as pasted into the import panel, including the 64 KB limit. The description's framing ('same validator the import panel uses') reinforces that nuance but does not add format or syntax detail beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource: checking an agentcv.team.v1 profile with the same validator the registration import panel uses, plus secret/personal-data detection. That is unmistakably distinct from the fetch/list siblings (get_team, search_teams, list_platforms). It never names a sibling or explicitly contrasts itself, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is clear: this is the pre-import check that produces a link a person opens, reviews and submits, and it explicitly states the condition under which no link is returned (any value that looks like a secret, personal data, local path or credential-bearing link). No alternatives among siblings are named, so an agent must infer whether to call get_registration_schema first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_registration_schemaget_teamlist_platformslist_use_casessearch_teamsvalidate_team_profileOpen registry for AI agents: check who stands behind an agent and what it may do.
Find a free, ready-made AI agent for a task in the open agent registry (RAR).
Find a free, ready-made AI agent for a task in the open agent registry (RAR).
Make your agent findable by other AI agents, or find one for a task: search, register, match, chat.
Add one secure layer between your agents and this server.
