Agoragentic

Server Quality Checklist

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

Latest release: v1.0.4
Disambiguation4/5
Most tools have distinct purposes with clear descriptions, but there is potential confusion between `agoragentic_browse_services` and `agoragentic_search` (both for discovering services), and between `agoragentic_quote`, `agoragentic_quote_service`, and `agoragentic_match` (all preview providers/pricing). The external marketplace tools also have overlapping scopes.
Naming Consistency3/5
The majority of tools follow the `agoragentic_verb_noun` pattern (e.g., `call_service`, `execute_status`). However, the five external marketplace tools use a different prefix (`explain_external_*`, `inspect_external_*`, etc.), breaking consistency. Names are generally readable but the mix of prefixes creates inconsistency.
Tool Count4/5
20 tools is slightly above the ideal range of 3-15, but each tool appears justified for the server's purpose (x402 services, marketplace execution, verification, external sources). The count is reasonable for a comprehensive agent commerce interface.
Completeness4/5
The server covers the full lifecycle for an agent marketplace: discovery, quoting, matching, execution, status polling, receipt verification, and registration. External marketplace integration is limited to inspection without execution. Minor gaps include no cancellation or refund tools, but core workflows are well-covered.
Average 4.1/5 across 20 of 20 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 4 of 4 community issues answered or closed in the last 6 months
- 337 commits in the last 12 weeks
- Last stable release on July 23, 2026
- 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.
View related servers

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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, covering safety. The description adds 'no-execution preview', which aligns, but does not disclose additional behavioral traits 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 a single sentence, concise but slightly awkward phrasing ('and a no-execution handoff preview'). Could be clearer, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so the description has a higher burden to explain what the tool returns. It mentions 'inspect' and 'preview' but does not specify what data or format is returned. Incomplete for a tool with no 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?
Only one parameter with 100% schema description coverage. The schema already explains the parameter. The description does not add extra meaning or usage context. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Inspect one local public-safe external supply candidate and a no-execution handoff preview.' The phrase 'no-execution handoff preview' is confusing and not fully clear. The title from annotations is clearer, but the description lacks specificity about what inspecting entails.
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 guidance on when to use this tool versus alternatives. There is a sibling 'preview_external_handoff' which could be related, but no differentiation is provided. The description does not state when or when not to use this tool.
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 readOnly=true and idempotent=true. The description adds valuable behavioral context: it performs hash recomputation and signature tamper detection, works anonymously, and can accept either a stored receipt ID or a presented JSON. This goes beyond 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 efficiently convey purpose, mechanism, and usage context. Every word adds value, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits the output of the verification (e.g., boolean, status, or error details). It also does not explain what happens when both parameters are provided or the relationship between receipt_id and receipt. Given the tool's role in a commerce interchange, these gaps hinder complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning: it confirms that receipt is a JSON object and that either parameter can be used, but the schema already provides clear descriptions ('Minted interchange receipt ID (areceipt2_...)' and 'Optional full receipt JSON').
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's purpose: verifying a minted interchange receipt via hash recomputation and signature tamper detection. It distinguishes itself from siblings by focusing on verification, while other tools like 'edge_receipt' or 'quote' serve different functions.
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 guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical scenarios, or exclusions, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds return field specifics but does not disclose additional traits like rate limits, auth requirements, or error behavior.
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 front-loads the core action ('Quote one stable x402 service by slug') and efficiently lists return items. It is appropriately sized with no wasted words.
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 moderate complexity (4 params, no output schema), the description covers purpose and return values comprehensively. It does not mention error conditions or edge cases, but annotations cover safety traits sufficiently.
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 input schema fully explains each parameter. The description adds no new semantic detail beyond what the schema provides, e.g., it mentions 'by slug' but the slug param already has a description.
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 quotes a stable x402 service by slug, listing exact return items (price, retry, trust metadata, sample input, payable URL). This distinguishes it from siblings like agoragentic_call_service (which spends) and generic quote tools.
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 phrase 'without spending' implies safe querying, but no explicit guidance on when to use this vs. alternatives (e.g., agoragentic_call_service for execution, agoragentic_quote for other contexts) or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds marginal value by stating 'public-safe'. It does not describe any additional behavioral traits beyond what annotations cover.
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 a single concise sentence that front-loads the action and resource. Every word serves a purpose; no wasted content.
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?
With no output schema, the description should clarify what the returned data contains (e.g., fields or structure). It only mentions 'normalized source snapshots' without elaboration, leaving the output ambiguous for an AI agent.
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, and schema description coverage is 100%. Per the criteria, 0 parameters defaults to baseline 4. The description does not add parameter info, which is acceptable since schema already covers all.
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 uses a specific verb 'List' and clearly identifies the resource as 'local public-safe external supply sources and normalized source snapshots'. It distinguishes itself from sibling tools like 'search_external_marketplaces' and 'inspect_external_supply_candidate', which have 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its alternatives. Given the presence of multiple sibling tools, explicit usage context is missing, which could lead to incorrect tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that the tool explains a boundary, which is consistent with read-only behavior. However, it does not disclose return format or any side effects beyond what annotations imply. Since annotations carry the safety burden, a 3 is appropriate.
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 a single, focused sentence that starts with the verb 'Explain'. It contains no extraneous words and clearly communicates the tool's purpose.
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, no output schema, and simple read-only nature, the description is mostly complete. However, it assumes familiarity with the boundary terms, which may require external context. A slight improvement would be to clarify the output format or provide an example.
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?
There are no parameters, so the baseline is 4. The description does not need to add parameter info.
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 uses the verb 'Explain' and specifies a concrete resource: the 'no-execution, no-spend, no-settlement, no-trust-mutation boundary' for external marketplace search. It distinguishes from siblings like search_external_marketplaces or inspect_external_supply_candidate by focusing on explanation rather than execution or inspection.
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. It does not mention prerequisites, when not to use, or suggest other tools for related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 that it returns counts, but does not disclose any additional behavioral traits beyond what annotations provide.
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 a single, concise sentence that efficiently communicates the tool's purpose without unnecessary words or repetition.
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 the simplicity of the tool (no parameters, no output schema), the description is complete: it specifies what the tool lists (categories) and what extra information is included (capability counts).
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 zero parameters, so the description need not add parameter details. Baseline of 4 is appropriate as no parameter information is missing.
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 the tool lists all available categories with capability counts, distinguishing it from sibling tools that browse, call, or execute services.
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 provide any guidance on when to use this tool versus alternatives or when not to use it, leaving the agent without contextual decision support.
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 (readOnly, idempotent, non-destructive), the description adds key behavioral insight: the tool does not invoke a paid service, meaning it is safe to call without incurring charges. This helps the agent understand cost implications.
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 a single sentence, front-loading the action 'List' and covering all key elements without redundancy. Every word earns its place, making it highly concise and well-structured.
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 tool's simplicity (one optional parameter, no output schema), the description covers the basic scope but lacks detail on the return format or meaning of technical terms like 'Argent/Themis high-risk posture'. For a read-only status tool, it is minimally adequate but not fully 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?
The parameter 'include_inactive' is fully described in the schema (100% coverage). The tool description adds no additional meaning or usage hints beyond what the schema already provides, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List' and specific resources: execution verifiers, high-risk posture, lifecycle states, and external verifier readiness. It distinguishes itself from sibling tools by focusing on verification status without paid service invocation.
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 for checking verifier status without cost, but it does not explicitly specify when to use this tool versus alternatives like agoragentic_execute_status. No exclusions or context for when not to use are provided.
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, destructiveHint, and idempotentHint, indicating safe read operation. The description adds value by listing specific actions it does not perform (e.g., 'does not call, execute, submit'), which provides extra behavioral clarity beyond what annotations offer. No contradictions are present.
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, consisting of two sentences. The first sentence delivers the core purpose, and the second sentence lists exclusions without unnecessary detail. Every word serves a purpose, making it efficient and easy to parse.
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 tool's simplicity and high schema coverage, the description is adequate but lacks information about the return format or behavior. It does not mention that the tool returns a list of candidates or how results are structured, which would be helpful for an agent invoking it without an 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 has 100% description coverage, so all 9 parameters are already documented with clear definitions. The description does not add any parameter-specific semantics beyond what the schema provides, earning a baseline score of 3.
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 the verb 'Search' and the resource 'local public-safe external marketplace supply metadata', which is specific and distinguishes it from siblings like 'list_external_supply_sources' or 'explain_external_marketplace_boundaries'. The negative list further clarifies what the tool does not do, reinforcing its read-only nature.
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 a read-only usage context through the negative list, but it does not explicitly state when to use this tool versus alternatives like 'agoragentic_search' or 'inspect_external_supply_candidate'. No comparison or exclusion criteria are provided, so the agent must infer usage from the tool's name and description alone.
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, idempotentHint, and destructiveHint false. The description adds that the receipt is anonymous and fetched from a specific domain, providing useful context beyond the annotations 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?
The description is a single sentence with no extraneous information. It is concise and front-loads the essential action and parameters.
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 simple fetch tool with one parameter and strong annotations, the description is largely sufficient. It lacks details about the response format or error conditions, but this is acceptable given no output schema and the tool's straightforward nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of receipt_id. The description does not add additional semantic value beyond the schema, so baseline score of 3 is appropriate.
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 the tool fetches a specific resource (anonymous x402 edge receipt) by a unique identifier (receipt ID) from a specific endpoint (x402.agoragentic.com). This distinguishes it from sibling tools like search or match, 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 implies usage when you have a receipt ID, but it does not explicitly mention when to use this tool versus alternatives like agoragentic_search. No exclusions or when-not guidance are provided.
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 indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true. Description adds valuable behavioral context: returns API key, automatic session binding, persistence advice. 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?
Description is concise and well-structured: registration action, return value, session behavior, persistence instructions. Slightly dense but every sentence adds value; could be slightly more terse.
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?
No output schema exists, but description clearly states the return value (API key). Covers session binding and key persistence. Could mention error handling (e.g., duplicate agent_name) but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters (agent_name, agent_type). The tool description does not add further parameter-specific meaning beyond what the schema provides, so baseline of 3 is appropriate.
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 clearly states 'Register as a new agent on Agoragentic' with specific output (API key, authenticated access). No sibling tool duplicates this purpose, and the verb 'Register' differentiates it effectively.
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?
Provides clear context for when to use: describes session binding behavior for new vs. existing authenticated sessions, and gives persistence instructions. However, it does not explicitly state when not to use or list alternatives, though none exist among 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 provide readOnlyHint, idempotentHint, openWorldHint, and destructiveHint. The description adds context that only supply-side listings are searched and that quoting/invoking is a separate step, which gives helpful scope without contradicting 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 sentence that efficiently conveys the core purpose and usage flow. It is appropriately front-loaded. Slightly more structure (e.g., separate sentence) could improve readability but is not necessary.
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 no output schema, the description hints at what is returned (listings with IDs that can later be quoted/invoked). All 4 parameters are covered in schema. For a read-only search tool, this provides sufficient completeness for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description does not need to add much param detail. The description mentions search term, category, and max_price in the context of browsing but provides no extra syntax or formatting 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Search', resource 'Agoragentic supply-side listings', and purpose 'browse public capabilities'. It distinguishes from sibling tools by noting the optional next steps (quote/invoke by ID).
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?
Description explicitly says when to use this tool ('when you want to browse public capabilities') and implies downstream actions (quote/invoke by ID). However, it does not explicitly mention alternative tools or 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, idempotentHint, and openWorldHint, covering safety and idempotency. The description adds value by specifying that services are 'anonymous' and 'accountless,' indicating no authentication is needed. This enhances transparency without contradicting 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 concise, consisting of two sentences that immediately state the action and purpose. It earns its place without extraneous details.
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 simplicity (3 optional parameters, no output schema, robust annotations), the description covers the essential context: the domain, the type of services, and the intended use case. It could hint at the return format, but is largely 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 coverage is 100%, so each parameter (limit, include_trust, include_schemas) is well-described in the schema. The description does not add extra parameter semantics, but the baseline score of 3 is appropriate since the schema already provides sufficient meaning.
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 the tool's purpose: 'Browse stable anonymous x402 services on x402.agoragentic.com.' It uses a specific verb and resource, and distinguishes itself as an accountless buyer catalog for bounded paid resources, which is helpful even without siblings.
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 provides a clear use case: 'Use this as the accountless buyer catalog for bounded paid resources.' Since there are no sibling tools, explicit alternatives are unnecessary, but the description could be more precise about when not to use it. Still, it gives adequate guidance.
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 a write operation (readOnlyHint=false). The description adds behavioral detail: first unpaid attempt returns Payment Required payload, and retry with payment_signature completes the call. 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?
Two sentences, no fluff, front-loaded with the main verb and resource. Every sentence is necessary.
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 absence of an output schema, the description adequately explains the payment flow and parameter roles (slug, payment_signature). However, it could mention what the response looks like after a successful paid call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description does not add new parameter details beyond what's 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Call') and resource ('stable x402 service by slug'), clearly distinguishing it from siblings like agoragentic_quote or agoragentic_execute by emphasizing the x402 payment protocol.
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 explains the two-step unpaid/paid process and mentions payment_signature for retry, providing clear context. However, it does not explicitly contrast with sibling tools or state when not to use.
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 discloses key behavioral traits: it returns a PAYMENT-REQUIRED challenge on first call and echoes the text on retry with payment signature. This adds context beyond the annotations (which show readOnlyHint=false, etc.). 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 that front-load the purpose and clearly explain the pipeline behavior. No wasted words.
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 test tool with only 2 parameters and no output schema, the description is adequate. It explains the flow (challenge then echo) and the optional parameter. It is complete enough for an AI agent to use 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 coverage is 100%, so both parameters are already documented in the schema. The description does not add new semantic information about the parameters; it reinforces their roles. Baseline of 3 is appropriate.
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 'Test the free x402 402->sign->retry pipeline against Agoragentic without spending real USDC.' It specifies the verb (test), the resource (x402 pipeline), and the behavior (returns challenge until retry with signature). This distinguishes it from sibling tools like 'agoragentic_call_service' or 'agoragentic_execute' which handle actual payments.
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 explains when to use this tool (testing the x402 pipeline without spending real USDC). It implies that for real payments, other tools should be used, but does not explicitly contrast with alternatives. The context of sibling tools provides additional differentiation.
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, destructiveHint, and idempotentHint. The description adds beyond annotations: it confirms no writing, no external service opening, and no execution/payment, and introduces the concept of 'redacted' preview, which provides additional behavioral context.
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?
A single sentence that is well-structured, front-loaded with the action, and contains no filler. Every part contributes meaning.
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 no output schema and simple input schema, the description adequately covers what the tool does and its constraints. It could hint at output format (e.g., 'returns a redacted receipt') but is sufficient for a preview tool.
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 all three parameters. The tool description does not add new meaning beyond the schema. Baseline 3 is appropriate as the description offers no extra parameter guidance.
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's purpose: preview a redacted external marketplace handoff receipt. It also clearly lists what it does NOT do (no writing, no external opening, no execution/payment), making it distinct from sibling tools like agoragentic_execute or agoragentic_quote.
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 implies usage context: use when you want to preview without side effects. It contrasts with operations that write or execute, but does not explicitly name alternatives. However, sibling tool names serve as implicit alternatives.
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 provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds context beyond annotations by explaining the two modes, auth requirements (listing-quote anonymous, task-quote requires API key), and output types. 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 concise, front-loading the main purpose, then detailing modes and auth. It's a single paragraph but clear and efficient. A more structured list could improve readability, but it's still well-organized.
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 read-only quote tool with 10 optional parameters and no output schema, the description fully explains what each mode returns (task: ranked providers; listing: price, trust, guidance). Covers auth, anonymity, and parameter roles. All essential context is provided.
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?
Schema coverage is 100% with all 10 parameters described. The description adds value by grouping parameters into modes (task vs. listing) and explaining purpose contextually (e.g., 'constraints' for task mode). This grouping is not 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 clearly states it creates a router-aware quote with two distinct modes (task and listing). It specifies verbs like 'Create' and 'returns' and distinguishes from sibling tools like agoragentic_quote_service by mentioning different use cases and outputs.
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 explicitly details when to use each mode: 'If you pass task + constraints' for task-quote and 'If you pass capability_id, listing_id, or slug' for listing-quote. It also clarifies auth requirements per mode. It does not explicitly exclude other tools but provides clear situational guidance.
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?
No annotations are provided, so the description fully carries the burden. It discloses that the tool is read-only, non-destructive, has no side effects, and describes error conditions ('missing_api_key'). It also details the output structure (matched providers, trust scores, estimated cost, routing rationale).
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 about 4 sentences, well-structured with the main purpose front-loaded. Every sentence adds value without redundancy. It is concise and informative.
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 the tool's complexity (4 parameters, no output schema, many sibling tools), the description is complete. It covers purpose, usage, behavioral traits, error handling, and expected output, providing an agent with all necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add parameter-specific information beyond what the schema already provides. Each parameter is well-documented in the schema, including defaults for 'prefer_trusted'.
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 the tool's purpose: 'Preview which providers the Agoragentic Router would select for a given task, without executing or spending USDC.' It uses specific verbs and resources, distinguishing it from siblings like agoragentic_execute.
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 explicitly says 'Use this before agoragentic_execute to compare providers, check pricing, and verify availability.' It provides clear usage context and mentions the API key requirement, though it lacks explicit when-not-to-use instructions.
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?
No annotations are provided, so the description fully carries the burden. It states it is read-only, has no side effects or USDC spend, requires an environment variable, and describes error responses (missing_api_key, invalid_invocation_id). This is comprehensive.
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 concise and front-loaded with purpose. It is a single paragraph that covers all necessary aspects. Minor improvement could be structuring the return JSON fields, but it is still effective.
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 simple one-parameter tool with no output schema, the description is remarkably complete. It covers purpose, usage, prerequisites, error cases, and return fields. No gaps remain for the agent.
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?
Schema coverage is 100% with a description of invocation_id. The tool description adds context about the expected format ('inv_abc123def456') and validation errors, which enhances understanding beyond 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 clearly states the tool checks status, output, cost, and receipt of a previous invocation. The verb 'check' and resource are specific, and it distinguishes from siblings like agoragentic_execute (launch) and agoragentic_edge_receipt (edge receipts).
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 explicitly says to use this for polling async results or retrieving receipt metadata. It does not explicitly exclude other uses, but the context is clear. No sibling differentiation is stated, but the purpose is clear enough.
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 indicate readOnly, openWorld, idempotent, and non-destructive traits. The description adds further behavioral details: 'No auth, no spend', 'Confirms settlement only: it does not verify service delivery, output quality, or counterparty identity.' It fully discloses limitations without contradicting 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 concise (4 sentences) and well-structured: function statement, scope, auth/spend note, and limitation. Every sentence adds value with no redundancy.
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?
While the description covers purpose, parameters, and behaviors well, it fails to describe the tool's output or return value. Since there is no output schema, the description should indicate what the tool returns (e.g., a boolean, transaction details, or confirmation object). This gap reduces completeness for an agent invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 5 parameters. The description adds extra semantics by explaining the optional matching logic: 'an amount must be accompanied by a payTo or payer' and clarifies network constraints ('must be Base mainnet if provided'). This goes beyond 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 clearly states it is a 'free read-only check that a Base-mainnet USDC transfer settled on-chain for a transaction hash'. It specifies the exact resource (USDC settlement on Base) and action (check), and distinguishes from sibling tools by focusing solely on settlement confirmation without verifying service delivery or identity.
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 explains when to use this tool (for any USDC-settled x402 payment on Base, not just Agoragentic invocations) and what is out of scope (non-USDC assets). It provides clear context, but does not explicitly contrast with sibling verification tools like 'interchange_verify_receipt' or 'edge_receipt', nor does it 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: potential USDC spending, non-idempotence, required environment variable, error handling (missing_api_key), and detailed success/failure response structures.
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?
Well-structured and efficient: key action upfront, critical warnings in bold, usage guidance, then return format. Every sentence adds value, and the length is appropriate for the tool's complexity.
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 output schema, the description fully specifies success/error JSON structures. Parameter documentation is thorough, and sibling tool context is provided. The description adequately covers all necessary information for tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds valuable context beyond property descriptions: examples for each parameter, explanation of dependencies (e.g., quote_id links to agoragentic_quote), and clarifies that input shape depends on provider API.
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 the tool's verb ('Execute a task') and resource ('Agoragentic Router / Marketplace'), explaining the flow (selects provider, invokes, returns result with receipt). It distinguishes from sibling tools by advising to use agoragentic_match for preview and agoragentic_search for discovery.
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 guidance on when to use this tool vs alternatives ('Prefer agoragentic_match first...', 'Use agoragentic_search...'), and warns against using it for read-only discovery. Also notes potential USDC spending and non-idempotency, setting clear user expectations.
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:

[![agoragentic-integrations MCP server](https://glama.ai/mcp/servers/rhein1/agoragentic-integrations/badges/card.svg)](https://glama.ai/mcp/servers/rhein1/agoragentic-integrations)

Score Badge

Copy to your README.md:

[![agoragentic-integrations MCP server](https://glama.ai/mcp/servers/rhein1/agoragentic-integrations/badges/score.svg)](https://glama.ai/mcp/servers/rhein1/agoragentic-integrations)

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/rhein1/agoragentic-integrations'

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