Search public A2A agents and inspect read-only Agent Card and endpoint checks.
Scored across 6 tools
get_agent, get_connection_plan, and verify_agent each target a clearly different concern (full record, connection metadata, stored verification checks). The three discovery tools (list_agents, search_agents, recommend_agents) overlap in surface area but their descriptions make the boundaries explicit: browse/paginate vs. keyword search vs. ranked capability matching with filters. An agent could still momentarily hesitate between list_agents and search_agents, keeping this just below a 5.
All six tools follow a strict verb_noun snake_case pattern: get_agent, get_connection_plan, list_agents, search_agents, recommend_agents, verify_agent. The noun is consistently the 'agent' domain object, with a qualifier only where needed (connection_plan).
Six tools is well within the ideal 3-15 range for a read-only directory service. Each tool maps to a distinct consumer workflow (browse, search, recommend, inspect, verify, connect), so no tool feels redundant or bolted on.
The read-only consumer lifecycle is well covered: discovery (list/search/recommend), full record retrieval, verification, and connection planning, with explicit escape hatches to full_record_url/get_agent. The main gap is publisher-side or feedback/reputation operations (e.g., submit an agent, read ratings), though the server appears intentionally scoped to read-only browsing.
Get a full public agent record by LocalMark ID, including original card and complete stored evidence. Collection previews are compact; this explicit detail tool is not truncated.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a safe, read-only, idempotent operation. The description adds useful behavioral context: it returns the original card and complete stored evidence, and unlike collection previews it is not truncated.
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 tightly written sentences front-load the core action and then clarify the distinction from collection previews. There is no wasted language.
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 simple single-parameter read tool with no output schema, the description adequately explains what is returned: a full public agent record including the original card and complete stored evidence. It does not cover error behavior, but the essential invocation and return context are present.
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 0%, and the single parameter is only labeled 'agent_id' in the schema. The description helps by mapping it to 'LocalMark ID,' but it does not clarify the ID format or provide any further parameter guidance.
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 verb and resource: 'Get a full public agent record by LocalMark ID.' It also distinguishes this detail tool from collection previews by contrasting compact previews with an explicit, non-truncated record.
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 makes clear this tool is for full detail rather than compact collection previews. It does not explicitly name sibling tools or state exclusions, but the usage context is clear enough for an agent to choose between detail and preview views.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read connection metadata for a public agent without connecting to it.
Accepts a LocalMark agent ID, Agent Card URL, endpoint URL or domain. Returns advertised interfaces, authentication scheme metadata, input/output modes, skill names and stored evidence. A publisher domain may be ambiguous. The plan never includes credentials and never authorizes a task or payment. Obtain explicit task authorization before using any endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), but the description adds substantive behavioral context beyond them: it does not connect, never includes credentials, never authorizes a task or payment, and the plan may surface a domain ambiguity. This is meaningful disclosure for a metadata-only tool.
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 the core purpose, then inputs, then outputs, then caveats and safety notes. Every sentence carries information; only the authorization sentence is slightly tangential to the tool itself, but it is a useful flow guardrail.
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 one param, no output schema, and safety annotations already in place, the description covers inputs, expected returns (interfaces, auth metadata, modes, skills, evidence), caveats, and safety limits. An agent has enough to call it correctly; pagination/formatting of the returned evidence is the only unwritten detail.
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 0% and the single 'target' parameter has no schema description, so the description must compensate. It does: it enumerates four accepted forms (LocalMark agent ID, Agent Card URL, endpoint URL, domain) and flags the domain-ambiguity caveat. It could go further on format/syntax expectations, but this is strong compensation for an undocumented param.
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?
States a specific verb and resource ('Read connection metadata for a public agent') plus the key constraint ('without connecting to it'), which separates it from the connect/execute tools. However, it never names or contrasts against the sibling tools (get_agent, verify_agent), so an agent must infer the boundary from the 'metadata-only' framing.
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?
Provides a clear usage constraint ('Obtain explicit task authorization before using any endpoint'), which is implied guidance for the downstream flow, and warns that 'a publisher domain may be ambiguous.' It does not state when to prefer this over get_agent or verify_agent, leaving selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse public agents with pagination and repair_links to read-only publisher diagnostics.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the "public agents" scope and pagination behavior, but the "repair_links" wording implies a side effect that sits uneasily with a read-only, idempotent annotation and is never clarified.
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 sentence with the core purpose front-loaded, which is efficient. However, the trailing repair_links clause is unclear enough that it reads as leftover noise rather than earning 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?
For a two-parameter list tool with no output schema, the description omits the pagination defaults and limits, what an agent record contains, and what repair_links actually does. Annotations cover safety but not the operational details an agent needs to call this correctly.
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?
Both parameters (limit, offset) have 0% schema description coverage, so the description carries the full naming burden. It says only "pagination," giving no default values, maximums, or ordering semantics, which does not compensate for the schema gap.
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?
"Browse public agents with pagination" states a clear verb and resource, but the trailing clause "repair_links to read-only publisher diagnostics" is garbled and leaves the tool's second claimed capability undefined. No sibling tool (search_agents, get_agent, recommend_agents) is referenced to sharpen the boundary.
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 word "public" implies scope but there is no explicit guidance on when to use this instead of search_agents, get_agent, or recommend_agents. The agent must infer the distinction from names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend agents for a capability or job with matching reasons and caveats.
Uses exactly the website/API ranking and stored observations, never a live
task. Filters are requirements, so an empty shortlist is valid. auth is
'none' or 'declared'; signature is 'verified'; protocol is JSONRPC,
HTTP+JSON or GRPC. a2a_confirmed requires the latest current-endpoint
read-only probe to confirm A2A; it does not prove task quality or safety.
Observation age is 1..168 hours. max_amount is a
non-negative amount in human-readable asset units (0.05 means 0.05 USDC
for a USDC asset) and requires both network and asset with known decimals.
No price conversion across assets is performed. Returns compact structured
results (4 KiB per record), total_matches, pagination, ranking_version and
evidence scope. Use full_record_url or get_agent for full stored details.
| Name | Required | Description | Default |
|---|---|---|---|
| auth | No | ||
| asset | No | ||
| limit | No | ||
| query | Yes | ||
| offset | No | ||
| network | No | ||
| protocol | No | ||
| signature | No | ||
| max_amount | No | ||
| a2a_confirmed | No | ||
| tls_reachable | No | ||
| checked_within_hours | No | ||
| a2a_response_within_hours | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the read-only/idempotent annotations: it discloses data provenance (stored ranking, no live task), the a2a_confirmed probe's limits ('does not prove task quality or safety'), no cross-asset price conversion, and per-record payload size. These are exactly the caveats an agent needs before trusting the results.
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?
Dense but front-loaded, leading with purpose and matching output. Each clause carries real constraint information; the only mild inefficiency is that filter-value enumerations are interleaved with caveats rather than grouped.
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 13-parameter tool with no output schema, the description still explains the return payload (compact records at 4 KiB, total_matches, pagination, ranking_version, evidence scope) and covers nearly every filter's semantics. An agent has enough to call it correctly and interpret results.
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?
With 0% schema description coverage across 13 params, the description carries the burden and largely succeeds: it enumerates auth values, protocol values (JSONRPC, HTTP+JSON, GRPC), the 1..168 hour observation window, and the max_amount format plus its network+asset-decimals requirement. Only query, limit/offset bounds, and tls_reachable remain undocumented.
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?
States a specific verb and resource: 'Recommend agents for a capability or job with matching reasons and caveats.' It also distinguishes itself from live-execution siblings by asserting it uses 'exactly the website/API ranking and stored observations, never a live task,' though it never names search_agents or list_agents explicitly.
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 implied rather than stated: filtering semantics ('Filters are requirements, so an empty shortlist is valid') and a handoff ('Use full_record_url or get_agent for full stored details') are given, but there is no explicit guidance on when to choose this over search_agents, list_agents, or get_connection_plan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search public agent names, descriptions and skills. Returns profile/card URLs and repair_links to stored publisher diagnostics; no task or probe is run.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is covered. The description adds real value beyond that: it names the return payload shape and explicitly states no task or probe executes, which is the key behavioral distinction from verification tools.
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 tight sentences with zero filler; the core purpose is front-loaded and the return contract follows immediately.
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 read-only search tool with no output schema, this covers purpose, payload, and a crucial non-effect guarantee. Only limit/pagination behavior is left unexplained, a minor gap against an otherwise complete definition.
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 0% for two parameters, so the description must carry the load. It usefully implies what the query matches against (names, descriptions, skills), but says nothing about the limit parameter, its default behavior, or pagination.
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?
States a specific verb and resource ("Search public agent names, descriptions and skills") plus a summary of what comes back (profile/card URLs, repair_links). It does not, however, distinguish itself from siblings like list_agents or recommend_agents, which an agent could easily confuse this with.
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 clause "no task or probe is run" implicitly excludes verify_agent-style probing, which is useful routing. But there is no explicit when-to-use guidance relative to list_agents (enumerate everything) or recommend_agents (ranked suggestions), so the agent must infer which entry point to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read stored checks for a card URL, endpoint URL or publisher domain.
Unseen targets return listing_status 'not_seen', including available
lookalike-domain hints. Publisher domains may return multiple matches.
No live request is made to the publisher.
| Name | Required | Description | Default |
|---|---|---|---|
| card_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered; the description then adds real value beyond them: unseen targets yield listing_status 'not_seen', lookalike-domain hints may be included, publisher domains can return multiple matches, and no live network request is issued. That is a meaningful behavioral profile; auth/permission or rate-limit details are the only notable omissions.
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?
Purpose is front-loaded in the first sentence and the remaining sentences each add distinct behavioral information without filler. Formatting is somewhat fragmented into short standalone lines, but nothing is wasted.
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 no output schema, the description correctly compensates by describing return semantics ('not_seen', lookalike hints, multiple matches for publisher domains) and the no-live-request behavior. Given one parameter and read-only annotations, this is largely complete; only auth/permission expectations are unspecified.
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?
With 0% schema coverage on a single card_url parameter, the description must carry the load, and it does: it discloses that the tool accepts a card URL, endpoint URL, or publisher domain, expanding what the lone schema field actually represents. This is a genuinely useful clarification, though it creates mild ambiguity about whether the value must specifically be a card_url as the schema name implies.
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 (read stored checks) and resource (card URL, endpoint URL, publisher domain), and clarifies the tool works against cached/stored data rather than a live check. It does not, however, name or contrast itself with the sibling get_agent, so the agent has to infer the boundary itself.
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 explicit when-to-use or when-not-to-use statement, and no alternative is named. The agent must infer from 'stored checks' and 'no live request' that this is the cached-lookup variant, but no selection guidance is given against get_agent or search_agents.
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.
recommend_agents1 field changedInput schema / properties / a2a_confirmedAdded value: +{
+ "default": false,
+ "title": "A2A Confirmed",
+ "type": "boolean"
+}get_connection_planrecommend_agentsverify_agentget_agentlist_agentssearch_agentsDiscover, search, invoke, and rate A2A (Agent-to-Agent) protocol agents.
Read-only checks for DIDs, credentials, MCP servers, A2A cards and agent delegation.
Search a public index of agents, MCP servers and skills found on the open web. Free, no auth.
Read-only search of the Agent Connectors MCP directory.
Add one secure layer between your agents and this server.
