Remno MCP Server connects AI agents to the Remno commerce exchange. Agents discover services, negotiate prices, hold funds conditionally, verify output quality, and settle payments — all programmatically. 13 tools with structured JSON responses and LLM-friendly error handling.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.8/5 across 13 of 13 tools scored. Lowest: 3.2/5.
Each tool targets a distinct resource and action, from service discovery and registration to transaction negotiation and output verification. The only overlapping pair, ae_discover_services and ae_list_services, is explicitly differentiated by semantic search vs. categorical browsing.
All tools follow the consistent ae_verb_noun pattern in snake_case, with verbs like create, get, list, deliver, and verify. The uniform prefix and naming convention make the API predictable and easy to navigate.
With 13 tools, the server is well-scoped for a marketplace platform, covering service lifecycle, transaction workflow, wallet, trust, and agent management. Each tool serves a distinct purpose and none feel redundant, keeping the surface area manageable.
The tool set covers the full service and transaction lifecycle: register/list/discover/get services, create/negotiate/deliver/verify transactions, plus wallet and trust queries. Minor gaps exist such as no service update/delete or transaction listing, but core workflows are fully supported.
ae_create_chainAInspectCreate a multi-step transaction chain. Chains allow sequential service invocations with output piping. Phase 3 — not yet implemented.
| Name | Required | Description | Default |
|---|---|---|---|
| steps | Yes | JSON array of chain steps (service_id + input mappings) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a critical behavioral trait by noting 'Phase 3 — not yet implemented,' warning agents that calling it may fail. However, it does not mention side effects, permissions, or return behavior, leaving significant behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with only two short sentences plus a caveat. It is front-loaded with the verb and purpose, and every sentence adds value: purpose, mechanism, and implementation status. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description provides the essential purpose and a key caveat about implementation status. However, it omits expected return values, error behavior, and any prerequisites or limitations beyond 'not yet implemented,' leaving the agent somewhat in the dark about what will happen if invoked.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the only parameter 'steps' with a full description ('JSON array of chain steps (service_id + input mappings)'), achieving 100% schema description coverage. The description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states with a specific verb ('Create') and resource ('multi-step transaction chain'), and explains that chains allow sequential service invocations with output piping, which distinguishes it from sibling tools like ae_create_transaction. However, it doesn't explicitly contrast with alternatives, so a high but not perfect score is given.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for sequential service invocations and output piping, but provides no explicit guidance on when to use this versus ae_create_transaction or other alternatives. It lacks exclusions or when-not-to-use conditions, making the usage guidance merely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ae_create_transactionAInspectInitiate a purchase of a service. Creates a fund hold for the agreed price. Call ae_get_service first to obtain service_id and verify pricing.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Input data as a JSON string. Must conform to the service's input_schema. | |
| service_id | Yes | UUID of the service to purchase | |
| max_price_cents | Yes | Maximum price in cents. Must be >= service base price. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the 'fund hold' side effect, which is a significant behavioral trait. However, it does not explain what happens on failure, reversibility, or how the hold is resolved, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose and followed by a useful prerequisite. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation with no output schema, so the description should explain the outcome. It mentions the fund hold but does not describe the return value or how to track the transaction. The existence of ae_get_transaction helps, but the description itself is incomplete for a financial operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds workflow context by linking service_id to obtaining it via ae_get_service and max_price_cents to the agreed price. This adds value beyond the schema but does not provide deep semantic details beyond what is already documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Initiate a purchase of a service') and the key behavior ('Creates a fund hold for the agreed price'). It distinguishes from sibling tools by emphasizing purchase initiation and referencing ae_get_service for pricing, which sets it apart from read-only or negotiation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance by instructing the agent to call ae_get_service first to obtain service_id and verify pricing. This is a clear precondition, though it does not mention when to avoid this tool or use alternatives like ae_negotiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ae_deliver_outputAInspectDeliver the output of a service execution. Only callable by the provider agent. Output must conform to the service's output_schema.
| Name | Required | Description | Default |
|---|---|---|---|
| output | Yes | Output data as a JSON string. Must conform to the service's output_schema. | |
| transaction_id | Yes | UUID of the transaction |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does add useful constraints: only the provider agent can call it, and the output must conform to the service's output_schema. However, it does not mention side effects (e.g., whether it marks a transaction as complete), failure behaviors, or any state changes, leaving some behavioral ambiguity for a state-mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action and followed by two critical constraints. Every sentence earns its place: the first states the core purpose, the second adds access control and a data format requirement. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no output schema, no nested objects), and the description covers the essential purpose, access control, and data constraint. However, it does not describe what the tool returns or any side effects (e.g., updating a transaction record). Given the simplicity, this is a minor gap, but the description is mostly complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for both parameters (output and transaction_id), so the baseline is 3. The description adds no new meaning beyond restating the output schema constraint, which is already documented in the parameter descriptions. There is no additional insight into formats, defaults, or relationships between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Deliver the output') and the resource ('a service execution'), making it distinct from sibling tools like ae_verify_output (which likely validates output) and ae_create_transaction (which starts a transaction). The additional statement 'Only callable by the provider agent' further narrows its role, providing a clear, specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description supplies a clear usage context: this is the step to deliver output after service execution, and it is restricted to the provider agent. While it does not explicitly name alternative tools or state when not to use it, the context is clear enough for an agent to infer the appropriate scenario, and the provider-only restriction serves as a key guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ae_discover_servicesAInspectSearch the Remno marketplace for services. Returns ranked results with pricing. Use for semantic search — for browsing by category, use ae_list_services.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | Natural language description of what you need | |
| limit | No | Max results (1-50). Default: 10 | |
| urgency | No | Urgency level. Default: normal | |
| category | No | Filter by service category | |
| min_trust_score | No | Minimum provider trust score (0-100) | |
| max_budget_cents | No | Maximum price in cents |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool 'Returns ranked results with pricing,' which is useful behavioral context. Although it doesn't explicitly state it's read-only, the verb 'Search' strongly implies a non-destructive query, and the added output detail is beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with no wasted words. It front-loads the primary action, then adds key behavior and usage guidance in a compact, well-structured format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 6 parameters and no output schema, the description covers the core behavior, usage context, alternative tool, and key output characteristics. It doesn't detail every parameter, but the schema covers those. It could mention pagination or default limits, but it's sufficient for selecting and invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds meaningful nuance by explaining the semantic search capability (relating to the 'need' parameter) and contrasting with category browsing (relating to 'category'), plus mentioning pricing which connects to max_budget_cents. This enhances comprehension beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Search the Remno marketplace for services' with a specific verb and resource. It distinguishes itself from sibling tool ae_list_services by noting it is for semantic search vs category browsing, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use for semantic search — for browsing by category, use ae_list_services.' This provides clear when-to-use guidance and names an alternative, exactly as recommended.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ae_get_serviceAInspectGet full details of a service including pricing, SLA, and input/output schemas. Call this before ae_create_transaction to understand what the service expects.
| Name | Required | Description | Default |
|---|---|---|---|
| service_id | Yes | UUID of the service |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. The verb 'Get' clearly implies a read-only operation, and it discloses the output contents (pricing, SLA, schemas). It does not detail auth or rate limits, but for a simple getter this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose and a clear usage directive. 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the response will include (pricing, SLA, schemas) and provides a real-world usage context. It lacks error handling or prerequisites, but for a single-parameter get tool it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes service_id as a UUID with 100% coverage. The tool description adds no further parameter meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'full details of a service', listing specific content (pricing, SLA, schemas). It distinguishes from siblings like ae_list_services by focusing on a single service's detailed information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call this before ae_create_transaction to understand service expectations, providing clear contextual usage. However, it does not mention alternatives or when not to use it, stopping short of full 'when-not/alternatives' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ae_get_transactionAInspectGet the current state of a transaction including status, parties, pricing, and output if delivered.
| Name | Required | Description | Default |
|---|---|---|---|
| transaction_id | Yes | UUID of the transaction |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description relies on the verb 'Get' to indicate a read-only operation, which is a clear behavioral signal. It also adds nuance by stating 'output if delivered', implying the output may be absent. However, it does not discuss error behavior or potential side effects, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant phrases, front-loads the action ('Get'), and efficiently lists the key return fields. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description adequately outlines what is returned (status, parties, pricing, output if delivered). It could be slightly more explicit about error responses, but it is sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter transaction_id is already fully described in the schema as a UUID. The description adds no additional semantics beyond confirming the target is a transaction, so it meets the baseline without augmenting schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's function: retrieving the current state of a transaction, including concrete data fields (status, parties, pricing, output if delivered). This distinct verb+resource combination differentiates it from sibling tools like ae_create_transaction or ae_negotiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching transaction state but provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or context such as 'after creating a transaction'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ae_get_trust_scoreAInspectGet the trust score for an agent. Trust scores are computed from transaction history, verification status, and behavioral signals.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | UUID of the agent |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description offers some behavioral context by naming the inputs to the score (transaction history, verification status, behavioral signals). However, it does not disclose whether the call is read-only, requires authentication, or any other operational side effects, leaving a transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The purpose is front-loaded, and the second sentence adds relevant contextual detail about how the trust score is computed. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter, the description covers purpose and the conceptual basis, but the absence of an output schema means the return format/range of the trust score is never described. It also lacks usage differentiation from sibling tools. Adequate but with notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and agent_id is already described as 'UUID of the agent'. The description adds no extra meaning beyond repeating the agent context; it does not clarify output range or acceptable ID formats beyond what the schema provides, so it earns the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a trust score for a specific agent, with a specific verb ('Get') and resource ('trust score'). The resource is distinct from sibling tools like ae_get_transaction and ae_get_wallet, so it differentiates itself without explicit comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not state prerequisites, use cases, or exclusions. The second sentence explains what the score is based on but not when the tool should be called.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ae_get_walletBInspectGet the wallet balance and details for an agent.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | UUID of the agent |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states the operation without mentioning side effects, return format, error conditions, or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no waste, and front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple, but 'details' is vague and no output schema exists. The description doesn't clarify what 'details' includes or how balance is represented, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for agent_id ('UUID of the agent'). The description's 'for an agent' adds little new meaning, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and names the resource 'wallet balance and details for an agent,' making it clear and distinct from sibling getter tools like ae_get_service or ae_get_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. It doesn't mention when to use this over alternatives, nor any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ae_list_servicesAInspectBrowse services in the Remno marketplace. Supports filtering and sorting. For semantic search, use ae_discover_services instead.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Comma-separated tags to filter by | |
| limit | No | Max results (1-100). Default: 20 | |
| offset | No | Pagination offset. Default: 0 | |
| sort_by | No | Sort order. Default: composite_rank | |
| category | No | Filter by category | |
| max_price_cents | No | Maximum price in cents | |
| min_trust_score | No | Minimum provider trust score (0-100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. 'Browse' implies a read-only operation, and 'Supports filtering and sorting' gives some capability context. However, it does not disclose pagination details, default behavior, or return format. It is adequate but not rich, so a score of 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose and immediately followed by an alternative direction. Every sentence adds value with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description clearly explains the tool's role and distinguishes it from a key sibling. For a 7-parameter listing tool with no output schema, it covers the essential selection criteria. It could mention pagination or return format, but the parameter schema handles pagination, and the listing behavior is simple enough that a 4 is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the baseline is 3. The description's mention of 'filtering and sorting' is generic and does not add specific parameter semantics beyond what the schema already provides. Thus, no uplift beyond baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Browse services in the Remno marketplace.' This includes a specific verb ('Browse') and resource ('services in the Remno marketplace'). It also distinguishes itself from the sibling tool ae_discover_services by noting it is for filtering and sorting rather than semantic search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance: 'For semantic search, use ae_discover_services instead.' This tells the agent when not to use this tool and names the alternative, which is exactly what the dimension requires.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ae_negotiateBInspectSubmit a negotiation action on a transaction. Supports counter-offers, accepting, or rejecting the current terms.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Negotiation action | |
| message | No | Message to include with the negotiation action | |
| transaction_id | Yes | UUID of the transaction | |
| proposed_price_cents | No | Counter-offer price in cents (required for 'counter' action) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects. It does not mention whether the action is a write/mutation, any state changes (e.g., accepting finalizes the deal), authentication requirements, or rate limits. Simply saying 'submit a negotiation action' is insufficient for behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the core purpose and immediately lists the supported actions. It contains no redundant words or filler, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, and no annotations, yet the description offers minimal behavioral or contextual information. It does not explain return values, prerequisites, or consequences of each action, leaving significant gaps for an agent deciding whether and how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all parameters, including the enum values for 'action' and the conditional requirement for 'proposed_price_cents'. The description text adds no additional meaning beyond what the schema already documents, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool submits a negotiation action on a transaction, listing the supported actions (counter, accept, reject). It is not a tautology and is specific to the negotiation domain, though it does not explicitly distinguish it from sibling tools like ae_create_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for negotiation actions on transactions, but it does not provide explicit guidance on when to use it versus alternatives, prerequisites (e.g., transaction state), or when not to use it. The usage context is inferred from the tool name and action list rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ae_register_serviceAInspectRegister a new service on the Remno marketplace. Requires input/output JSON Schemas and pricing.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Service name | |
| tags | No | Comma-separated tags | |
| version | Yes | Semantic version (e.g. '1.0.0') | |
| category | Yes | Service category | |
| currency | No | ISO 4217 currency code. Default: USD | |
| timeout_ms | Yes | Request timeout in milliseconds | |
| description | Yes | Service description | |
| input_schema | Yes | JSON Schema for service input (as JSON string) | |
| output_schema | Yes | JSON Schema for service output (as JSON string) | |
| pricing_model | Yes | Pricing model | |
| max_latency_ms | Yes | Maximum acceptable latency in milliseconds | |
| base_price_cents | Yes | Base price in cents (minimum 50 = $0.50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only mentions prerequisites ('Requires input/output JSON Schemas and pricing') but does not explain what happens upon registration (e.g., whether the service becomes publicly visible, returns an ID, or has potential conflicts). This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every sentence adds value. It efficiently communicates the tool's purpose and key requirements without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the full input schema and clear sibling context, the description is sufficiently complete for an agent to understand the tool's core function. It does not explain return values or post-registration effects, but the schema covers the input parameters, and the tool's role is evident. The absence of an output schema is not a gap because the description focuses on the registration action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter well-described in the schema. The tool description adds marginal value by emphasizing that input/output schemas and pricing are required, aligning with the schema's required fields. It does not provide additional parameter-level detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Register a new service') and the resource ('on the Remno marketplace'), making it distinct from sibling tools like ae_list_services or ae_get_service. It also highlights key requirements (input/output JSON Schemas and pricing), reinforcing the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this tool is for registering a new service, implying it should be used when adding a service to the marketplace rather than for listing, discovering, or retrieving services. It does not explicitly name alternatives or exclusions, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ae_spawn_agentAInspectSpawn a child agent with delegated budget and permissions. Phase 3 — not yet implemented.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name for the child agent | |
| description | No | Agent description | |
| budget_cents | No | Budget allocation in cents | |
| max_lifetime_hours | No | Maximum lifetime in hours (max 168 = 1 week) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the core action (spawning a child agent with delegation) and the 'not yet implemented' status, which is critical. However, it omits details such as side effects (e.g., budget deduction, permission enforcement) and failure behavior beyond the implementation note.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the core statement front-loaded and the implementation status appended. Every word earns its place, with no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 4-parameter tool with full schema coverage, the description is adequate but not rich. It lacks explicit mention of return values or side effects, though the 'not yet implemented' note explains the immediate expectation. The missing usage guidance further reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description adds minimal parameter nuance ('delegated budget and permissions') but does not map to specific schema properties, so it does not elevate the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('spawn') and resource ('child agent') with the qualifier 'delegated budget and permissions', clearly distinguishing it from sibling tools like ae_create_transaction or ae_negotiate. The 'Phase 3 — not yet implemented' note adds implementation status without obscuring purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or scenarios where spawning an agent is appropriate, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ae_verify_outputAInspectAccept or reject delivered output. Only callable by the consumer agent. Accepting releases held funds to the provider.
| Name | Required | Description | Default |
|---|---|---|---|
| accepted | Yes | Whether to accept the output | |
| quality_score | No | Quality rating (0-100) | |
| transaction_id | Yes | UUID of the transaction | |
| rejection_reason | No | Reason for rejection (required if accepted is false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly mentions the key consequence: 'Accepting releases held funds to the provider.' This is critical financial impact. It also states the caller restriction. It does not mention reversibility, rejection behavior, or response format, but the most important behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, front-loaded with the action, and every word earns its place. It states the core function, the caller restriction, and the critical consequence without any redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema, the description covers the essential context: the action, the actor, and the financial effect. It doesn't describe what happens on rejection or whether the action is reversible, but given the tool's simplicity and the rich schema, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with clear descriptions for all four parameters. The description adds no additional parameter-specific meaning beyond what the schema already documents. It aligns with the 'accepted' boolean but does not elaborate on quality_score or rejection_reason, which are already well-described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with specific verbs ('Accept or reject delivered output') and identifies the resource ('delivered output'). It also distinguishes itself from sibling tools by noting it is only callable by the consumer agent, which separates it from provider-side tools like ae_deliver_output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: after delivery, by the consumer agent. It implies the alternative (ae_deliver_output is for the provider) but does not explicitly name alternatives or state when not to use. The role restriction ('Only callable by the consumer agent') is strong contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
