Skip to main content
Glama

Nexez Agentic Commerce

by ai.nexez
OverviewDiscussionsAdmin

Server Details

Find Nexez sellers, inspect offers, and validate checkout or negotiation before buyer approval.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
89.6% over 41 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.4/5.0

Scored across 5 tools

Disambiguation5/5

Each tool targets a distinct stage in the workflow: broad browsing vs. ranked search, manifest inspection, checkout validation, and negotiation validation. The descriptions include explicit cross-references that eliminate real ambiguity. Even the two dry-run validators are clearly separated by checkout vs. negotiation.

Naming Consistency4/5

Most tools follow a clear verb_noun pattern (get_page, validate_checkout, validate_negotiation), and all share the nexez_ prefix and snake_case. nexez_directory and nexez_search are minor deviations because directory is a noun rather than a verb and search stands alone, but the pattern remains readable and predictable.

Tool Count5/5

Five tools is a well-scoped size for a discovery-and-validation server: browse, search, inspect, validate checkout, and validate negotiation. Each tool has a distinct responsibility and none feels like filler or redundant.

Completeness4/5

The set covers the full pre-transaction workflow: discover, inspect, and dry-run validate both checkout and negotiation. The only notable gap is that it never executes a purchase or submits a negotiation, but the descriptions consistently frame this as a forced dry-run/validation boundary rather than an oversight.

Available Tools

5 tools
nexez_directoryBrowse the Nexez directoryA
Read-only
Inspect

Browse published Nexez listings without requiring a buyer query. All filters are optional. Returns directory JSON text with listing summaries and readiness information. Use nexez_search when you need ranked matches for a specific buyer request.

ParametersJSON Schema
NameRequiredDescriptionDefault
qNoOptional case-insensitive text filter across listing name, description, audience, and location.
categoryNoMarketplace category; defaults to all.
locationNoOptional city or region filter matched against published location and service-area information.
min_readinessNoMinimum listing readiness score, normally 0-100; defaults to 0 (no threshold).

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint, covering safety. The description adds useful behavior beyond annotations by specifying that results are returned as directory JSON text with listing summaries and readiness information, and that filtering is entirely optional. It does not mention pagination or ordering, but for a read-only browsing tool this is not a critical gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: purpose and scope, optional filtering, and a pointer to the sibling tool. The information is front-loaded and free of filler.

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 read-only directory tool with 100% schema coverage and full annotation coverage, the description is complete. It explains what the tool returns in the absence of an output schema and clearly identifies when to use nexez_search instead, leaving no critical gap for an agent deciding whether to call it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents every parameter and its meaning. The description adds only the general statement that all filters are optional, which is already implied by zero required parameters. It does not add syntax, formatting, or interaction details 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 states a specific verb ('browse') and resource ('published Nexez listings'), and clearly distinguishes itself from nexez_search by noting it does not require a buyer query. It also states the return type (directory JSON text with summaries and readiness information), making the tool's purpose unmistakable.

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?

The description explicitly says to use nexez_search when ranked matches for a specific buyer request are needed, providing a clear alternative and boundary. It also clarifies that all filters are optional and that browsing requires no buyer query, which tells the agent when this directory tool is the right choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

nexez_get_pageInspect a Nexez listingA
Read-only
Inspect

Fetch one listing's structured agent manifest as JSON text, including seller profile, offers, configuration requirements, and published actions. Use a slug returned by search or directory; inspect exact offer identifiers and requirements before validation.

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYesExact published listing slug returned by nexez_search or nexez_directory, not a full URL.

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context by specifying the output as JSON text and listing the manifest sections included, plus the workflow purpose. It does not contradict the annotations; it complements them.

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 two tight sentences with no redundancy. The first sentence states the core action and output contents; the second gives operational guidance. Every clause earns its place.

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, single-parameter read-only tool with 100% schema coverage and no output schema, the description provides sufficient information: what is returned, how to obtain the slug, and why to use the tool. It also fits into the surrounding tool workflow, making it complete for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage for the single 'slug' parameter is 100%, including the explicit note that it is not a full URL and must come from nexez_search or nexez_directory. The description echoes this and adds usage intent, but does not materially deepen parameter semantics 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 identifies the action ('Fetch'), the resource ('one listing's structured agent manifest'), and the output format ('as JSON text'). It also enumerates the manifest contents (seller profile, offers, configuration requirements, published actions), distinguishing it from the search, directory, and validation sibling tools.

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?

The description explicitly states the slug source ('returned by search or directory') and the recommended workflow position ('inspect exact offer identifiers and requirements before validation'). This gives the agent clear guidance on when to call this tool relative to its siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

nexez_validate_checkoutValidate Nexez checkoutA
Read-only
Inspect

Dry-run checkout for an exact published offer. Returns validation JSON text with offer readiness or errors and missing requirements. Inspect the offer with nexez_get_page first. Never charges or creates an order; a successful check is not a completed purchase.

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYesExact published listing slug returned by discovery, not a full URL.
offerYesExact offer key from the listing manifest, for example services-0 or products-1. Do not invent an index.
queryNoOptional buyer context
buyerEmailNoOptional buyer-provided email for checkout context. Omit when unnecessary; never invent personal details.
buyerReferenceNoOptional buyer-provided reference for checkout context; omit if none was supplied.
offerConfigurationNoBuyer-selected configuration values keyed exactly as defined by the target offer configuration schema from nexez_get_page. Supply required fields for that offer; do not invent values or use a generic schema.

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds meaningful behavioral context beyond the readOnlyHint=true and destructiveHint=false annotations: 'Never charges or creates an order; a successful check is not a completed purchase.' It also discloses the nature of the return value, which is valuable since no output schema is 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 three concise sentences with no filler. It front-loads the core purpose and return value, then adds the prerequisite and the critical non-charge guarantee. Every sentence earns its place.

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?

The description is complete for a dry-run validation tool: it explains purpose, output shape, prerequisites, and the safety guarantee. Despite having no output schema, it clearly states what the agent will receive in response. The detailed input schema covers parameter semantics, so nothing critical is missing.

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 already fully documents all six parameters. The description adds no parameter-specific detail, but the schema provides clear guidance such as 'not a full URL' and 'Do not invent an index,' making this baseline 3 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 states a specific action ('Dry-run checkout') and a specific resource ('an exact published offer'), and clarifies the return value ('validation JSON text with offer readiness or errors and missing requirements'). This clearly distinguishes it from sibling tools like nexez_get_page or nexez_validate_negotiation.

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 instructs the agent to inspect the offer with nexez_get_page first, establishing a clear prerequisite. It also clarifies when not to interpret a successful result as a completed purchase, though it does not explicitly contrast this with nexez_validate_negotiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

nexez_validate_negotiationValidate Nexez negotiationA
Read-only
Inspect

Evaluate proposed terms against an exact offer and the seller's published rules in a forced dry run. Returns rules-evaluation JSON text or validation errors. Inspect the offer first and supply its required terms. Never submits a proposal, contacts a seller, or writes a negotiation.

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYesExact published listing slug returned by discovery, not a full URL.
offerYesExact offer key from the listing manifest, for example services-0 or products-1.
queryNoBuyer request describing the desired work or product and relevant context.
budgetNoBuyer-proposed budget or range as text, using the offer currency, for example USD 500. Do not invent a budget.
contactNoOptional buyer contact route.
timelineNoBuyer-proposed delivery timing as text, for example within 4 weeks. Use requestedTerms.projectWeeks for a numeric duration rule.
requestedTermsNoStructured buyer proposal. Published seller rules may require scope (text or list of deliverables), revisionCount (whole number 0-1000), and projectWeeks (whole number 1-1000). Example: {"scope":"Logo and brand guide","revisionCount":2,"projectWeeks":4}. Inspect the offer rules; omit unknown terms rather than inventing them.

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds important behavioral context beyond those annotations: it is a forced dry run, it returns rules-evaluation JSON text or validation errors, and it never submits or writes. This exceeds the minimal burden and gives a clear safety profile.

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 two sentences, front-loads the core action and return type, and then gives the critical prerequisite ('Inspect the offer first') and negative side-effect guarantees. Every sentence earns its place and there is no repetition of schema content.

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 validation tool with 7 parameters, 100% schema coverage, and no output schema, the description is complete enough: it explains the dry-run mode, the expected inputs, and the return type. It does not describe the exact shape of the rules-evaluation JSON, but since there is no output schema and the tool is a validator, a little more about the evaluation result structure could help. Still, the description covers the critical context needed to call it safely.

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 every parameter. The description itself adds some value by telling the agent to inspect offer rules and omit unknown terms rather than inventing them, which is meaningful usage guidance for the requestedTerms object. However, most parameter meaning lives 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 states a specific verb ('Evaluate'), the resource ('proposed terms against an exact offer and the seller's published rules'), and mode ('forced dry run'). It clearly distinguishes itself from a live submission and names what it returns ('rules-evaluation JSON text or validation errors'). This is distinct from siblings like nexez_validate_checkout.

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?

The description explicitly says to inspect the offer first and supply its required terms. It also explicitly lists what it never does ('Never submits a proposal, contacts a seller, or writes a negotiation'), which tells the agent when NOT to expect side effects and implies it is for pre-submission validation. This is strong when-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updates
    • Changednexez_directory4 fields changed
      • addedInput schema / properties / category / description
        Added value: +"Marketplace category; defaults to all."
      • addedInput schema / properties / location / description
        Added value: +"Optional city or region filter matched against published location and service-area information."
      • addedInput schema / properties / min_readiness / description
        Added value: +"Minimum listing readiness score, normally 0-100; defaults to 0 (no threshold)."
      • addedInput schema / properties / q / description
        Added value: +"Optional case-insensitive text filter across listing name, description, audience, and location."
    • Changednexez_get_page1 field changed
      • changedInput schema / properties / slug / description
        Previous value: -"Listing slug"New value: +"Exact published listing slug returned by nexez_search or nexez_directory, not a full URL."
    • Changednexez_search10 fields changed
      • addedInput schema / properties / category / description
        Added value: +"Marketplace category; omit or use all to include both professional and consumer listings."
      • addedInput schema / properties / industry / description
        Added value: +"Case-insensitive substring filter on the published industry, for example plumbing."
      • addedInput schema / properties / lat / description
        Added value: +"Optional latitude context metadata. Does not filter or rerank results; use location for geographic filtering."
      • changedInput schema / properties / limit / description
        Previous value: -"Max results (default 10)"New value: +"Maximum results; defaults to 10 and is rounded down and clamped to 1-50."
      • addedInput schema / properties / lng / description
        Added value: +"Optional longitude context metadata. Does not filter or rerank results; use location for geographic filtering."
      • addedInput schema / properties / min_readiness / description
        Added value: +"Minimum listing readiness score (0-100); omit for no readiness threshold."
      • addedInput schema / properties / min_trust / description
        Added value: +"Minimum marketplace trust score (0-100); omit for no trust threshold. Not a guarantee of seller performance."
      • addedInput schema / properties / price_band / description
        Added value: +"Filter by the listing marketplace price band. Inspect the exact offer for its price and currency; this is not a checkout quote."
      • addedInput schema / properties / supports_negotiation / description
        Added value: +"Filter by negotiation availability: true for eligible listings, false for non-negotiable listings; omit to include both."
      • addedInput schema / properties / verified / description
        Added value: +"Filter by seller verification signal: true requires a signal, false requires its absence; omit to include both."
    • Changednexez_validate_checkout5 fields changed
      • addedInput schema / properties / buyerEmail / description
        Added value: +"Optional buyer-provided email for checkout context. Omit when unnecessary; never invent personal details."
      • addedInput schema / properties / buyerReference / description
        Added value: +"Optional buyer-provided reference for checkout context; omit if none was supplied."
      • changedInput schema / properties / offer / description
        Previous value: -"e.g. services-0 or products-1"New value: +"Exact offer key from the listing manifest, for example services-0 or products-1. Do not invent an index."
      • changedInput schema / properties / offerConfiguration / description
        Previous value: -"Canonical buyer values required by the target offer configuration schema."New value: +"Buyer-selected configuration values keyed exactly as defined by the target offer configuration schema from nexez_get_page. Supply required fields for that offer; do not invent values or use a generic schema."
      • addedInput schema / properties / slug / description
        Added value: +"Exact published listing slug returned by discovery, not a full URL."
    • Changednexez_validate_negotiation6 fields changed
      • addedInput schema / properties / budget / description
        Added value: +"Buyer-proposed budget or range as text, using the offer currency, for example USD 500. Do not invent a budget."
      • addedInput schema / properties / offer / description
        Added value: +"Exact offer key from the listing manifest, for example services-0 or products-1."
      • addedInput schema / properties / query / description
        Added value: +"Buyer request describing the desired work or product and relevant context."
      • changedInput schema / properties / requestedTerms / description
        Previous value: -"Optional structured terms the buyer wants the seller to review."New value: +"Structured buyer proposal. Published seller rules may require scope (text or list of deliverables), revisionCount (whole number 0-1000), and projectWeeks (whole number 1-1000). Example: {\"scope\":\"Logo and brand guide\",\"revisionCount\":2,\"projectWeeks\":4}. Inspect the offer rules; omit unknown terms rather than inventing them."
      • addedInput schema / properties / slug / description
        Added value: +"Exact published listing slug returned by discovery, not a full URL."
      • addedInput schema / properties / timeline / description
        Added value: +"Buyer-proposed delivery timing as text, for example within 4 weeks. Use requestedTerms.projectWeeks for a numeric duration rule."
  2. 1 tool update
    • Changednexez_validate_negotiation2 fields changed
      • addedInput schema / properties / contact
        Added value: +{
+  "description": "Optional buyer contact route.",
+  "type": "string"
+}
      • addedInput schema / properties / requestedTerms
        Added value: +{
+  "description": "Optional structured terms the buyer wants the seller to review.",
+  "type": "object"
+}
  3. 1 tool update
    • Changednexez_search2 fields changed
      • addedInput schema / properties / nexez_checkout_ready
        Added value: +{
+  "description": "Owner payout state confirms Nexez-settled checkout readiness",
+  "type": "boolean"
+}
      • addedInput schema / properties / supports_checkout / description
        Added value: +"Deprecated compatibility filter: any actionable offer or provider handoff"
  4. 1 tool update
    • Changednexez_validate_checkout3 fields changed
      • addedInput schema / properties / buyerEmail
        Added value: +{
+  "type": "string"
+}
      • addedInput schema / properties / buyerReference
        Added value: +{
+  "type": "string"
+}
      • addedInput schema / properties / offerConfiguration
        Added value: +{
+  "description": "Canonical buyer values required by the target offer configuration schema.",
+  "type": "object"
+}
  5. 1 tool update
    • Changednexez_search8 fields changed
      • addedInput schema / properties / category
        Added value: +{
+  "enum": [
+    "all",
+    "professional",
+    "consumer"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / industry
        Added value: +{
+  "type": "string"
+}
      • addedInput schema / properties / min_readiness
        Added value: +{
+  "maximum": 100,
+  "minimum": 0,
+  "type": "integer"
+}
      • addedInput schema / properties / min_trust
        Added value: +{
+  "maximum": 100,
+  "minimum": 0,
+  "type": "integer"
+}
      • addedInput schema / properties / price_band
        Added value: +{
+  "enum": [
+    "free",
+    "under_100",
+    "100_500",
+    "500_2000",
+    "2000_plus",
+    "custom"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / supports_checkout
        Added value: +{
+  "type": "boolean"
+}
      • addedInput schema / properties / supports_negotiation
        Added value: +{
+  "type": "boolean"
+}
      • addedInput schema / properties / verified
        Added value: +{
+  "type": "boolean"
+}
  6. 5 tool updates
    • First observednexez_directory
    • First observednexez_get_page
    • First observednexez_search
    • First observednexez_validate_checkout
    • First observednexez_validate_negotiation

Related MCP Connectors

Related MCP Servers

  • merx

    kamilkubik89
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents to discover products, verify signed catalog feeds, negotiate within published policies, and place mandate-bound orders with signed receipts via MCP, A2A, or REST.
    MIT

  • glongus-mcp

    glongusmain
    A
    license
    A
    quality
    B
    maintenance
    Enables AI agents to search, inspect, and purchase physical goods on an escrow-secured marketplace, including listing search, agent reputation checks, and offer creation.
    5
    25 npm
    MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources