stellar-agent-search

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Each tool has a clear, distinct purpose covering search, ranking, profiles, listings, feedback, reputation, and registry health. A minor overlap exists between get_agent_profile and get_agent_card, but both descriptions explicitly differentiate their roles.
Naming Consistency4/5
Almost all tools follow a consistent verb_noun pattern (e.g., find_agent, rank_agent, list_services). The exceptions are leaderboard (noun only) and get_agents_by_owner (uses 'by'), but these are minor deviations that do not impede understanding.
Tool Count5/5
With 13 tools, the server covers all essential operations for an agent search and registry exploration server without being overwhelming. The count is well-scoped for the domain.
Completeness5/5
The tool set provides comprehensive coverage of the search/exploration domain: discovery, ranking, detailed profiles, service listings, feedback, reputation verification, and registry health. No obvious gaps are present for the stated purpose.
Average 4/5 across 13 of 13 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 67 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. The description adds significant context about the contract's limitations (holes, bounded reachability), the fact that checks return unavailable with explicit scope, and clarifies that it does not call get_summary. This goes beyond annotations without contradicting them.
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 description is relatively long and technical, explaining underlying contract mechanics. While it provides necessary context, it could be more concise for quick comprehension. The front-loaded content is clear, but the detail level might hinder readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool and the presence of an output schema (not shown but indicated), the description adequately explains the tool's behavior and limitations. However, it does not mention return value structure, relying on the output schema.
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?
The input schema covers 100% of the single parameter 'agent' with detailed types and descriptions. The description does not add extra parameter information, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool is for reputation observation of a single agent, using a fail-closed approach. It distinguishes from siblings by specifying that it does not call get_summary or claim a diff, but it could more explicitly differentiate from rank_agent and similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like rank_agent or leaderboard. It implies a scenario where reputation verification is needed but lacks guidance on when not to use it or what prerequisites are required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable context: specific metric definitions, a 5,000-agent sample cap, non-global distribution warning, and snapshot limitations. This goes beyond the annotations to inform the agent of important constraints.
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?
The description is a single sentence that is concise yet packed with relevant information. It front-loads the core purpose and follows with specific constraints. It earns its place without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description does not need to detail return values. It covers key caveats like sample cap and distribution warning, making it sufficiently complete for a simple stats retrieval tool.
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?
The tool has no parameters, so the description doesn't need to explain parameter usage. The baseline for zero parameters is 4, and the description appropriately focuses on the tool's output and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'registry counts plus sampled metrics' and lists specific features like sample cap and warnings. It effectively communicates the purpose of retrieving registry stats, though it does not explicitly differentiate from sibling tools like get_registry_health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions constraints (sample cap, non-global distribution warning) but does not provide explicit guidance on when to use this tool versus alternatives such as get_registry_health or leaderboard. Given the number of sibling tools, more context on use cases is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds behavioral context: owner addresses expand an API page with a limit of 20, and coverage indicates if more rows exist. This discloses pagination behavior and result structure, adding value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. Every word is informative, and key points are front-loaded. It is appropriately sized for the tool's simplicity.
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?
For a single-parameter tool with high schema coverage and an output schema, the description is complete: it explains input types, behavior with owner addresses, and pagination. No additional details are needed.
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?
The input schema has 100% description coverage and already lists all accepted reference formats. The description does not add new semantics beyond what is in the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves various agent references to canonical identifiers, specifying input types (id, numeric string, stellar handle, owner G-address). It is specific about verb and resource, but does not explicitly contrast with sibling tools, though the resolution function is distinct from listing or ranking tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like find_agent or get_agents_by_owner. It implies usage for resolving references but does not set context, exclusions, or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds value by noting pagination coverage reporting and the 'selfDeclared' slot in output, which are not in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused sentences with no wasted words. Front-loaded with the primary action, followed by needed details and output structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and good annotations, the description covers pagination and key output details. Minor gaps include explanation of the 'verify' parameter and the '3-axis engine' ranking mechanism.
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?
With only 33% schema description coverage, the description compensates partially by mentioning limit (up to 20 agents) and owner ('owner endpoint'). However, the 'verify' parameter is unexplained, and details about the ranking engine are vague.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists agents for a given owner, with pagination and ranking. It distinguishes from siblings like list_agents (generic) and find_agent (search). However, the phrase 'owner endpoint's current page' is slightly ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need agents for a specific owner, but does not explicitly state when not to use or mention alternatives like list_agents. Usage context is implicit but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond annotations by explaining the source (Explorer-indexed), trust model (client-authored, untrusted), sanitization, and the handling of revoked entries (hidden unless includeRevoked is set). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that convey the core purpose, data source, trust implications, and a key behavioral detail (revoked entries). Every word adds value; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters (1 required) and an output schema, the description covers the essential aspects: what the tool returns, the nature of the data, and an important filter condition. It does not mention pagination defaults or sorting, but these are often self-evident or covered by the output schema. The description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, meaning several parameters (tag, page, limit, includeRevoked) lack descriptions in the schema. The tool description does not compensate by explaining these parameters or their usage. It only mentions the 'includeRevoked' behavior, leaving agents without sufficient guidance on how to correctly set 'tag', 'page', or 'limit'.
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 clearly states that the tool retrieves recent Explorer-indexed on-chain feedback for a single agent. It specifies that feedback is client-authored and untrusted, stored in a 'selfDeclared' slot, and sanitized. This distinguishes it from sibling tools like 'rank_agent' or 'get_agent_profile' which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like 'find_agent' or 'verify_reputation'. There is no indication of when not to use it or which scenarios it is best suited for, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by noting that the current probe verifies no reputation fields, no A2A conformance or endpoint ownership is implied, and self-declared text is confined to labeled slots. This clarifies the limits of the data returned.
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?
The description is relatively concise but dense with information. It front-loads the list of included components and then clarifies limitations. Each sentence adds value, though it could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description adequately covers the tool's overall behavior and the key components returned. It does not need to detail return values. However, the mention of 'rank breakdown' and 'Reputation-contract reachability status' could be more precise without relying solely on the schema.
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 67%. The description does not add significant new semantic information beyond the schema's parameter descriptions. The explanation of the verify parameter is mostly redundant with the schema description, and the agent parameter is already well-documented in the schema.
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 it returns the full profile for one agent, listing specific components (typed identity, capabilities, declared scores, rank breakdown, Reputation-contract reachability status, recent feedback, canonical handle, and A2A-shaped projection). This clearly differentiates from sibling tools like find_agent, rank_agent, or get_agent_card.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. While it implies usage for obtaining a full agent profile, it lacks guidance on exclusions or specific contexts where other sibling tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds extensive behavioral details: bounded scan/filter, per-axis breakdown, optional on-chain verification, coverage state, and self-declared text slots, going well beyond annotations.
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?
The description is relatively short and front-loaded with the core purpose. However, it uses domain-specific jargon that may reduce clarity for some agents. Every sentence adds value, but could be more accessible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (not shown in input), the description covers key aspects: boundedness, 3-axis, breakdown, verification, coverage, self-declared. It does not mention return format or pagination, but those may be in output schema. Adequate for the complexity.
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 50%, and the description adds context for verify (optional verification) and trust (enum meaning) but does not explain mpp, x402, limit, hasServices, or minExplorerScore beyond schema. It partially compensates for missing schema descriptions but not fully.
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 clearly states it retrieves top-ranked agents via a bounded registry scan with per-axis breakdown, using a 3-axis engine. It distinguishes itself from siblings like find_agent or rank_agent by specifying leaderboard-specific features (bounded scan, breakdown, on-chain verification).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as rank_agent or list_agents. The description implies usage for leaderboard queries but does not provide context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, open-world hints. The description adds specific behavioral details: pagination, ranking by 3-axis engine, and a labeled selfDeclared slot. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no superfluous content. Front-loaded with key info: paginated, filterable, ranking. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description does not need to detail return values. It covers filtering, pagination, ranking, and a key field (selfDeclared). For a list tool with 10 params (0 required), this is nearly complete.
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 only 40%, and the description does not explain individual parameters beyond listing their names. It adds minimal parameter meaning beyond what the schema provides, but lists the filter keys as context.
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 clearly states it is a paginated, filterable listing of registered agents, ranked by a 3-axis engine. This explicitly defines the verb (list), resource (agents), and scope (filtered/paginated), and differentiates it from sibling tools like find_agent or rank_agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists available filters but does not provide explicit guidance on when to use this tool versus alternatives like find_agent or resolve_agent. It implies usage for listing/filtering but lacks use-or-not-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds that the projection is unverified, not an official AgentCard, and that owner-authored data is under card.selfDeclared, exceeding annotation context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all essential and front-loaded with the core purpose. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema is present (hidden), so return values need not be detailed. The description sufficiently explains the nature of the result and its limitations for a tool with 2 parameters and no nested objects.
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%, so the schema already documents both parameters adequately. The description adds no parameter-specific meaning beyond the schema, meeting the baseline.
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 clearly states it retrieves an 'unverified A2A-shaped projection' from indexed metadata, distinguishing it from an official AgentCard. This separates it from siblings like get_agent_profile and verify_reputation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description warns that the projection is not agent-published and proves neither conformance nor endpoint ownership, implying when not to use it. However, it does not explicitly name alternative tools for verified info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, etc.), the description adds critical context: endpoints are not probed for liveness/conformance, and labels are unverified. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key functionality and filter options, then limitations. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and presence of output schema, description covers data nature and filtering well. Could add note on pagination but not required since schema covers it.
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 63%. Description adds meaning for filters like x402, mpp, trust, minExplorerScore, and notes minScore is deprecated. However, page and limit are left to schema, which may be insufficient for complete understanding.
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 clearly states it is a catalog of self-declared service endpoint candidates with filtering options. It distinguishes from siblings like 'list_agents' by focusing on services.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists filter parameters but does not explicitly state when to use this tool versus alternatives. It implies use for unverified service discovery, lacking direct comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context by explaining the meaning of staleness and its implications, without contradicting 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that immediately convey the tool's purpose and a key nuance about staleness. Every sentence adds value without redundancy.
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 no parameters, strong annotations, and an existing output schema (not shown), the description is complete. It covers the returned data, the affected indexers, and a behavioral insight, leaving no gaps for a simple health check tool.
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?
The input schema has no parameters, so schema coverage is 100%. The description does not need to add parameter information; it remains concise and assumes the schema is sufficient.
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 clearly states that the tool returns per-registry indexer health, including last indexed ledger and staleness for three specific indexers: identity, reputation, and validation. It uses precise terminology and distinguishes the tool's purpose from siblings like get_registry_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not provide explicit guidance on when to use it versus alternatives. There is no mention of prerequisites, exclusions, or comparative context with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as readOnly, idempotent, and non-destructive. The description adds valuable behavioral details: the deterministic policy, that on-chain checks are metadata-only and never inflate rank, and that output includes breakdown and verification blocks. No contradictions with annotations.
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?
The description is a single paragraph that packs significant information without wasted words. It could benefit from bullet points for clarity, but it remains concise and front-loaded with the core policy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the existence of an output schema, the description covers the key aspects: ranking formula, XOR requirement, deprecated parameter, and output structure. It lacks a brief note on pagination or sorting, but these are inferable from the schema.
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 67% with 4 of 6 parameters described. The description adds context like the XOR constraint and the deprecation of 'weights', but does not explain 'limit' or 'sortBy' beyond schema defaults. This is adequate but not exemplary.
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 explicitly states the tool ranks agents using a deterministic evidence policy, specifying the exact formula. It distinguishes from siblings like 'find_agent' by requiring XOR between agentIds and query, making its purpose clear and unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states the XOR condition ('Provide EITHER agentIds OR query') and warns that 'weights' is deprecated and rejected. However, it does not explicitly describe when to prefer this over siblings like 'leaderboard' or 'verify_reputation', leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the tool's safety is clear. Description adds valuable behavioral context about the unverified nature of results and the natural-language ranking logic, which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states the core purpose and return type, second provides usage guidance and a crucial caveat. No wasted words, front-loaded with the most important 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?
Despite 10 parameters, the description is sufficient given high schema coverage (80%) and the presence of an output schema. It covers the tool's purpose, usage context, and a key trust caveat, making it complete for an agent to select and invoke correctly.
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 80%, so baseline is 3. Description adds no further detail on parameters beyond schema, but the schema itself already documents most parameters well. The description does flag the deprecated minScore parameter as rejected, which is helpful but minor.
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?
Description explicitly states 'Natural-language discovery of on-chain Stellar agents' with a specific verb and resource. It differentiates from siblings rank_agent and get_agent_profile by naming them and clarifying their distinct roles.
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?
Provides explicit when-to-use context and alternatives: 'Use rank_agent for per-axis breakdowns and get_agent_profile for full detail.' Also warns that agent names/descriptions are self-declared and unverified, indicating caution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![stellar-agent-search MCP server](https://glama.ai/mcp/servers/berkingurcan/stellar-agent-search/badges/card.svg)](https://glama.ai/mcp/servers/berkingurcan/stellar-agent-search)

Score Badge

Copy to your README.md:

[![stellar-agent-search MCP server](https://glama.ai/mcp/servers/berkingurcan/stellar-agent-search/badges/score.svg)](https://glama.ai/mcp/servers/berkingurcan/stellar-agent-search)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/berkingurcan/stellar-agent-search'

If you have feedback or need assistance with the MCP directory API, please join our Discord server