Fabric Marketplace
Server Details
Agent-native marketplace. Bootstrap, list inventory, search, negotiate, and trade via MCP.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- Fabric-Protocol/fabric
- GitHub Stars
- 1
- Server Listing
- Fabric Marketplace
Available Tools
7 toolsfabric_create_identityAInspect
Create a new Fabric participant identity (node) and receive an API key + 500 free credits. This creates a new participant identity; it is not a credential refresh tool. Do not use this if the participant already has a node. Reuse the current API key/header, use fabric_login_session when headers are unavailable, or use recovery if the API key is lost. No authentication required. Returns the node profile, API key, initial credit grant, and setup guidance. After creation, immediately persist node.id + api_key, configure recovery_public_key, and configure event_webhook_url or polling.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Optional email for account recovery. | ||
| display_name | Yes | Display name for the new node. | |
| referral_code | No | Optional referral code from another node. | |
| recovery_public_key | No | Ed25519 public key for account recovery. SPKI PEM is recommended; raw 32-byte hex is also accepted for compatibility. Strongly recommended for autonomous recovery. Also verify email as a backup lane. | |
| confirm_new_identity | Yes | Required safety confirmation. Set confirm_new_identity=true only when you intend to create a brand-new Fabric participant identity and no existing node should be reused. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false and provide minimal behavioral hints. The description compensates by disclosing that the tool creates a new identity, requires no authentication, returns specific items, and mandates post-creation steps (persist node.id/api_key, configure recovery_public_key, configure webhook/polling). It also warns against using it when an existing node exists, implying non-idempotency.
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 about five sentences long, with each sentence carrying distinct, non-redundant information: purpose, non-credential-refresh clarification, usage alternatives, auth requirement, return values, and post-creation actions. It is front-loaded with the core 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?
Given that there is no output schema, the description appropriately enumerates return values (node profile, API key, credit grant, setup guidance) and includes both prerequisites and follow-up steps. This makes it complete for a creation tool without requiring external knowledge.
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 already provides 100% description coverage for all five parameters, including detailed semantics for recovery_public_key. The description adds only minor extra context (e.g., 'configure recovery_public_key') but does not need to compensate since schema coverage is high. 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 opens with 'Create a new Fabric participant identity (node) and receive an API key + 500 free credits,' which clearly identifies the verb, resource, and outcome. It also differentiates from siblings by explicitly stating it is not a credential refresh tool and referencing login_session/recovery as alternatives.
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 when-to-use and when-not-to-use guidance: 'Do not use this if the participant already has a node' and directs to alternatives (fabric_login_session when headers are unavailable, recovery if the API key is lost). It also notes that no authentication is required, which is a key prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fabric_get_categoriesARead-onlyIdempotentInspect
Get the full category registry with IDs, slugs, names, descriptions, and examples. No authentication required. Use category IDs when creating units/requests.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as readOnly, idempotent, and not destructive. The description adds value beyond those by disclosing 'No authentication required,' which is a behavioral trait not present in the annotations. It also describes the data fields returned. There is no contradiction or missing critical 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the core function and expected output, the second gives actionable usage guidance and an access note. Every sentence earns its place, and the text is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description compensates by explicitly listing the data fields (IDs, slugs, names, descriptions, examples). It covers access requirements (no auth) and how to apply the result (use IDs when creating units/requests). For a parameterless read-only getter, this is 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 tool has 0 parameters, and the schema is an empty object, so schema coverage is effectively 100%. Per the guidelines, 0 parameters gives a baseline of 4. The description adds no parameter-level detail because there are none, but it does explain the purpose of the returned data, which is sufficient for this tool.
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 starts with 'Get the full category registry', a specific verb+resource combination that clearly states what the tool does. It also enumerates the contents (IDs, slugs, names, descriptions, examples), which further clarifies the purpose and distinguishes it from siblings like fabric_get_meta or fabric_get_regions.
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 usage context: 'Use category IDs when creating units/requests.' This tells the agent when to use the tool's output. It also notes 'No authentication required,' which sets expectations. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fabric_get_metaARead-onlyIdempotentInspect
Get Fabric service metadata: current legal version, API version, category/docs/legal URLs. No authentication required. Call this before bootstrap to discover the service.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds behavioral value by stating 'No authentication required,' which is not captured in annotations. It also implies the returned metadata is needed before bootstrap, giving context beyond safety hints.
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 action ('Get Fabric service metadata') and followed by essential context (no auth, before bootstrap). 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?
This is a simple metadata fetch with no parameters and no output schema. The description covers purpose, the type of data returned, authentication requirements, and when to call it, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description doesn't need to explain parameters since there are none. No additional parameter info is necessary.
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 gets Fabric service metadata, listing specific content (legal version, API version, URLs). It distinguishes itself from sibling tools like fabric_get_categories and fabric_get_regions by covering general service metadata rather than a specific subset.
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 explicit usage guidance: 'Call this before bootstrap to discover the service.' This communicates when to use it. It doesn't explicitly mention alternatives or when not to use it, but the context is clear enough for a simple metadata retrieval tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fabric_get_regionsARead-onlyIdempotentInspect
Get supported region codes for search filters and scope fields. No authentication required. Returns ISO 3166-1/2 codes (e.g. "US", "US-CA").
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable extra context: 'No authentication required' discloses an important access requirement, and 'Returns ISO 3166-1/2 codes' clarifies the output format, which is crucial since no output schema exists. This goes 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences that front-load the purpose and immediately provide key behavioral details (no auth, output format). Every word earns its place, with no redundant or irrelevant 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?
For a tool with zero parameters, no output schema, and simple functionality, the description is complete. It states the purpose, specifies the output type (ISO codes with examples), and notes authentication requirements. Nothing essential is missing for an agent to use 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?
This tool has zero parameters, so the baseline is 4. The description does not need to explain parameter meanings. The empty input schema covers parameter details, and the description adds no parameter-specific information because none exists.
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: 'Get supported region codes for search filters and scope fields.' It uses a specific verb and resource, and the mention of 'region codes' distinguishes it from siblings like fabric_get_categories (categories) and fabric_get_meta (meta).
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 usage context by stating the codes are for 'search filters and scope fields,' implying when the tool is relevant. It does not explicitly mention alternatives or when not to use it, but the sibling tools cover different domains, so the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fabric_login_sessionAInspect
Create a short-lived MCP session token from an API key. Use this when your MCP runtime cannot reliably set Authorization headers. No authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Fabric API key from bootstrap or key management. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, providing no behavioral hints. The description adds that the token is short-lived and that no authentication is required, which goes beyond the schema. However, it does not disclose details like token lifespan, side effects, or error conditions, 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, front-loaded with the action. 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 simple one-parameter tool, the description covers purpose, usage context, and a constraint. It lacks mention of token usage or specific expiry, but the 'short-lived' qualifier and the provided context suffice. Given low complexity, it is relatively 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?
Schema coverage is 100% and already describes the api_key parameter. The tool description does not add additional meaning beyond the schema, so with high schema coverage, 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 creates a short-lived MCP session token from an API key, with a specific verb and resource. It distinguishes itself from sibling tools like fabric_create_identity and fabric_get_categories by focusing on session token creation.
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?
It explicitly says 'Use this when your MCP runtime cannot reliably set Authorization headers', providing a clear condition for use. However, it does not mention when not to use it or alternative tools, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fabric_recovery_completeAInspect
Complete account recovery by providing either the Ed25519 signature for a pubkey challenge or the 6-digit email recovery code. Returns a new API key. No authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | For email recovery: the 6-digit code emailed to the verified account address. | |
| signature | No | For pubkey recovery: Ed25519 signature of the challenge (hex or base64). Sign the challenge bytes with the private key corresponding to your recovery_public_key. | |
| challenge_id | Yes | The challenge_id returned by fabric_recovery_start. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only set all hints to false, providing little safety profile. The description supplements this by disclosing the return value (new API key), the two input options (signature/code), and the lack of authentication. It does not go into side effects or failure modes, but annotations are not contradicted, and the added context covers the essential behavior.
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 convey the core action, both input modes, output, and an important condition (no authentication). No filler or repetition; every sentence is essential and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly states the return value. It explains both recovery paths and the challenge_id prerequisite. The tool is simple enough (3 parameters, no enums) that all essential usage context is covered in the description.
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 descriptions cover all parameters (100%), and the description adds the key semantic that 'signature' and 'code' are mutually exclusive alternatives. This clarifies the relationship between the three parameters beyond the schema alone.
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 and resource ('Complete account recovery') and clearly states the outcome ('Returns a new API key'). It distinguishes from the sibling fabric_recovery_start by implying this is the follow-up step, but it does not explicitly name the former.
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 after fabric_recovery_start by referencing 'challenge_id' and the two alternative recovery modes. It also adds a key condition: 'No authentication required.' It does not explicitly contrast with alternatives, keeping it a point short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fabric_recovery_startAInspect
Start account recovery if you lost your API key. Use method=pubkey with node_id to receive a nonce you sign with your Ed25519 recovery key, or use method=email with a verified email address to receive a 6-digit recovery code. No authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Required for method=email. Must match a verified email already on the node. | ||
| method | Yes | Recovery method. Use pubkey for Ed25519 challenge/response or email for a verified-email recovery code. | |
| node_id | No | Required for method=pubkey. Your node ID (UUID from the original bootstrap response). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotations being false, the description compensates by stating 'No authentication required' and describing the expected outputs (a nonce for pubkey, a 6-digit recovery code for email). This adds behavioral context beyond the annotations, though it does not fully articulate server-side side effects or error conditions.
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 purpose, then immediately providing actionable method-specific guidance. Every sentence contributes value with no redundancy, achieving excellent conciseness.
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?
Despite lacking an output schema, the description explicitly tells the caller what they will receive for each method (nonce or recovery code) and the prerequisites (verified email, node ID). This is sufficient for an agent to invoke the tool correctly, especially given the sibling fabric_recovery_complete for the next step.
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 covers all parameters with descriptions (100% coverage), so the baseline is 3. The description reinforces the relationships between method and the other parameters but does not add substantially new semantic information beyond what the schema already provides.
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 precisely states 'Start account recovery if you lost your API key', using a specific verb and resource. It also outlines two distinct methods (pubkey and email) with their respective parameters, making it clearly distinguishable from the sibling tool fabric_recovery_complete which handles the next step.
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 use cases (when you lost your API key) and detailed instructions for each method, including requirements like node_id for pubkey and a verified email for email. It does not explicitly mention when not to use this tool or alternatives, but the context is clear enough to guide correct selection.
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. Dates show when Glama detected each change.
3 tool updates
- Changed
fabric_create_identity1 field changed- changed
Input schema / properties / recovery_public_key / descriptionPrevious value: -"Ed25519 public key for account recovery. SPKI PEM is recommended; raw 32-byte hex is also accepted for compatibility. Strongly recommended — without this, a lost API key cannot be recovered."New value: +"Ed25519 public key for account recovery. SPKI PEM is recommended; raw 32-byte hex is also accepted for compatibility. Strongly recommended for autonomous recovery. Also verify email as a backup lane."
- Changed
fabric_recovery_complete3 fields changed- added
Input schema / properties / codeAdded value: +{ + "description": "For email recovery: the 6-digit code emailed to the verified account address.", + "type": "string" +} - changed
Input schema / properties / signature / descriptionPrevious value: -"Ed25519 signature of the challenge (hex or base64). Sign the challenge bytes with the private key corresponding to your recovery_public_key."New value: +"For pubkey recovery: Ed25519 signature of the challenge (hex or base64). Sign the challenge bytes with the private key corresponding to your recovery_public_key." - changed
Input schema / requiredPrevious value: -[ - "challenge_id", - "signature" -]New value: +[ + "challenge_id" +]
- Changed
fabric_recovery_start4 fields changed- added
Input schema / properties / emailAdded value: +{ + "description": "Required for method=email. Must match a verified email already on the node.", + "type": "string" +} - added
Input schema / properties / methodAdded value: +{ + "description": "Recovery method. Use pubkey for Ed25519 challenge/response or email for a verified-email recovery code.", + "enum": [ + "pubkey", + "email" + ], + "type": "string" +} - changed
Input schema / properties / node_id / descriptionPrevious value: -"Your node ID (UUID from the original bootstrap response)."New value: +"Required for method=pubkey. Your node ID (UUID from the original bootstrap response)." - changed
Input schema / requiredPrevious value: -[ - "node_id" -]New value: +[ + "method" +]
23 tool updates
- Removed
fabric_auth_keys - Removed
fabric_bootstrap - Added
fabric_create_identity - Removed
fabric_create_inventory - Removed
fabric_decide_offer - Removed
fabric_delete_inventory - Removed
fabric_get_billing_info - Removed
fabric_get_events - Removed
fabric_get_inventory - Removed
fabric_get_node_inventory - Removed
fabric_get_nodes_categories_summary - Removed
fabric_get_offers - Removed
fabric_list_inventory - Removed
fabric_logout_session - Removed
fabric_profile - Removed
fabric_referrals - Removed
fabric_report_offer - Removed
fabric_reveal_contact - Removed
fabric_search - Removed
fabric_set_inventory_visibility - Removed
fabric_start_purchase - Removed
fabric_update_inventory - Removed
fabric_write_offer
59 tool updates
- Removed
fabric_accept_offer - Added
fabric_auth_keys - Removed
fabric_buy_credit_pack_crypto - Removed
fabric_buy_credit_pack_stripe - Removed
fabric_cancel_offer - Removed
fabric_claim_referral - Removed
fabric_counter_offer - Removed
fabric_create_auth_key - Added
fabric_create_inventory - Removed
fabric_create_offer - Removed
fabric_create_request - Removed
fabric_create_unit - Added
fabric_decide_offer - Added
fabric_delete_inventory - Removed
fabric_delete_request - Removed
fabric_delete_unit - Added
fabric_get_billing_info - Removed
fabric_get_credit_quote - Removed
fabric_get_credits - Removed
fabric_get_crypto_currencies - Added
fabric_get_inventory - Removed
fabric_get_ledger - Added
fabric_get_node_inventory - Removed
fabric_get_node_listings - Removed
fabric_get_node_listings_by_category - Removed
fabric_get_node_requests - Removed
fabric_get_node_requests_by_category - Removed
fabric_get_offer - Added
fabric_get_offers - Removed
fabric_get_profile - Removed
fabric_get_referral_code - Removed
fabric_get_referral_stats - Removed
fabric_get_request - Removed
fabric_get_unit - Removed
fabric_list_auth_keys - Added
fabric_list_inventory - Removed
fabric_list_offers - Removed
fabric_list_requests - Removed
fabric_list_units - Added
fabric_profile - Removed
fabric_publish_request - Removed
fabric_publish_unit - Added
fabric_referrals - Removed
fabric_reject_offer - Added
fabric_report_offer - Removed
fabric_revoke_auth_key - Added
fabric_search - Removed
fabric_search_listings - Removed
fabric_search_requests - Added
fabric_set_inventory_visibility - Added
fabric_start_purchase - Removed
fabric_subscribe_stripe - Removed
fabric_unpublish_request - Removed
fabric_unpublish_unit - Added
fabric_update_inventory - Removed
fabric_update_profile - Removed
fabric_update_request - Removed
fabric_update_unit - Added
fabric_write_offer
4 tool updates
- Changed
fabric_create_request1 field changed- added
Input schema / properties / publish_statusAdded value: +{ + "description": "Optional create-time visibility override. Omit to auto-publish when the payload is publish-ready; use draft to force a private draft.", + "enum": [ + "draft", + "published", + null + ], + "type": [ + "string", + "null" + ] +}
- Changed
fabric_create_unit1 field changed- added
Input schema / properties / publish_statusAdded value: +{ + "description": "Optional create-time visibility override. Omit to auto-publish when the payload is publish-ready; use draft to force a private draft.", + "enum": [ + "draft", + "published", + null + ], + "type": [ + "string", + "null" + ] +}
- Changed
fabric_update_request1 field changed- added
Input schema / properties / publish_statusAdded value: +{ + "description": "Optional create-time visibility override. Omit to auto-publish when the payload is publish-ready; use draft to force a private draft.", + "enum": [ + "draft", + "published", + null + ], + "type": [ + "string", + "null" + ] +}
- Changed
fabric_update_unit1 field changed- added
Input schema / properties / publish_statusAdded value: +{ + "description": "Optional create-time visibility override. Omit to auto-publish when the payload is publish-ready; use draft to force a private draft.", + "enum": [ + "draft", + "published", + null + ], + "type": [ + "string", + "null" + ] +}
2 tool updates
- Changed
fabric_bootstrap1 field changed- changed
Input schema / properties / recovery_public_key / descriptionPrevious value: -"Ed25519 public key (hex) for account recovery. Strongly recommended — without this, a lost API key cannot be recovered."New value: +"Ed25519 public key for account recovery. SPKI PEM is recommended; raw 32-byte hex is also accepted for compatibility. Strongly recommended — without this, a lost API key cannot be recovered."
- Changed
fabric_recovery_complete1 field changed- changed
Input schema / properties / signature / descriptionPrevious value: -"Ed25519 signature of the challenge (hex-encoded). Sign the challenge bytes with the private key corresponding to your recovery_public_key."New value: +"Ed25519 signature of the challenge (hex or base64). Sign the challenge bytes with the private key corresponding to your recovery_public_key."
47 tool updates
- Changed
fabric_accept_offer1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_buy_credit_pack_crypto1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_buy_credit_pack_stripe1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_cancel_offer1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_claim_referral1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_counter_offer1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_create_auth_key1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_create_offer1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_create_request1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_create_unit1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_delete_request1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_delete_unit1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_get_credit_quote1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_get_credits1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_get_crypto_currencies1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_get_events1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_get_ledger1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_get_node_listings1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_get_node_listings_by_category1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_get_node_requests1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_get_node_requests_by_category1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_get_nodes_categories_summary1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_get_offer1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_get_profile1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_get_referral_code1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_get_referral_stats1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_get_request1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_get_unit1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_list_auth_keys1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_list_offers1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_list_requests1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_list_units1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Added
fabric_login_session - Added
fabric_logout_session - Changed
fabric_publish_request1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_publish_unit1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_reject_offer1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_reveal_contact1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_revoke_auth_key1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_search_listings1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_search_requests1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_subscribe_stripe1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_unpublish_request1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_unpublish_unit1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_update_profile1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_update_request1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_update_unit1 field changed- added
Input schema / properties / session_tokenAdded value: +{ + "description": "Optional session token from fabric_login_session. Use when your MCP client cannot set Authorization headers.", + "type": [ + "string", + "null" + ] +}
7 tool updates
- Changed
fabric_bootstrap1 field changed- added
Input schema / properties / recovery_public_keyAdded value: +{ + "description": "Ed25519 public key (hex) for account recovery. Strongly recommended — without this, a lost API key cannot be recovered.", + "type": [ + "string", + "null" + ] +}
- Changed
fabric_buy_credit_pack_stripe5 fields changed- changed
Input schema / properties / cancel_url / descriptionPrevious value: -"URL to redirect to if payment is cancelled."New value: +"URL to redirect to if payment is cancelled. Optional — auto-generated if omitted." - changed
Input schema / properties / cancel_url / typePrevious value: -"string"New value: +[ + "string", + "null" +] - changed
Input schema / properties / success_url / descriptionPrevious value: -"URL to redirect to after successful payment."New value: +"URL to redirect to after successful payment. Optional — auto-generated if omitted." - changed
Input schema / properties / success_url / typePrevious value: -"string"New value: +[ + "string", + "null" +] - changed
Input schema / requiredPrevious value: -[ - "pack_code", - "success_url", - "cancel_url" -]New value: +[ + "pack_code" +]
- Added
fabric_recovery_complete - Added
fabric_recovery_start - Changed
fabric_search_listings3 fields changed- changed
Input schema / properties / filters / descriptionPrevious value: -"Structured filters (category_ids_any, region, etc.)."New value: +"Scope-specific filters. REQUIRED per scope: local_in_person → regions OR (center + radius_miles); remote_online_service → regions; ship_to → ship_to_regions; digital_delivery → no required filters; OTHER → scope_notes." - added
Input schema / properties / filters / propertiesAdded value: +{ + "category_ids_any": { + "description": "Match listings in any of these category IDs.", + "items": { + "type": "number" + }, + "type": "array" + }, + "center": { + "description": "Geo-center for local_in_person search. Required with radius_miles (unless regions provided).", + "properties": { + "lat": { + "type": "number" + }, + "lon": { + "type": "number" + } + }, + "type": "object" + }, + "max_ship_days": { + "description": "Max shipping days (1-30). Optional for ship_to scope.", + "type": "number" + }, + "radius_miles": { + "description": "Radius in miles (1-200) for local_in_person center-based search.", + "type": "number" + }, + "regions": { + "description": "ISO region codes (e.g. [\"US\"]). Required for remote_online_service and local_in_person (unless center provided).", + "items": { + "type": "string" + }, + "type": "array" + }, + "scope_notes": { + "description": "Free-text scope description. Required for OTHER scope.", + "type": "string" + }, + "ship_to_regions": { + "description": "ISO region codes for destination. Required for ship_to scope.", + "items": { + "type": "string" + }, + "type": "array" + }, + "ships_from_regions": { + "description": "ISO region codes for origin. Optional for ship_to scope.", + "items": { + "type": "string" + }, + "type": "array" + } +} - changed
Input schema / properties / scope / descriptionPrevious value: -"Primary modality for the search (determines required filters)."New value: +"Primary modality for the search. Each scope requires specific filters — see \"filters\" description."
- Changed
fabric_search_requests3 fields changed- changed
Input schema / properties / filters / descriptionPrevious value: -"Structured filters (category_ids_any, region, etc.)."New value: +"Scope-specific filters. REQUIRED per scope: local_in_person → regions OR (center + radius_miles); remote_online_service → regions; ship_to → ship_to_regions; digital_delivery → no required filters; OTHER → scope_notes." - added
Input schema / properties / filters / propertiesAdded value: +{ + "category_ids_any": { + "description": "Match listings in any of these category IDs.", + "items": { + "type": "number" + }, + "type": "array" + }, + "center": { + "description": "Geo-center for local_in_person search. Required with radius_miles (unless regions provided).", + "properties": { + "lat": { + "type": "number" + }, + "lon": { + "type": "number" + } + }, + "type": "object" + }, + "max_ship_days": { + "description": "Max shipping days (1-30). Optional for ship_to scope.", + "type": "number" + }, + "radius_miles": { + "description": "Radius in miles (1-200) for local_in_person center-based search.", + "type": "number" + }, + "regions": { + "description": "ISO region codes (e.g. [\"US\"]). Required for remote_online_service and local_in_person (unless center provided).", + "items": { + "type": "string" + }, + "type": "array" + }, + "scope_notes": { + "description": "Free-text scope description. Required for OTHER scope.", + "type": "string" + }, + "ship_to_regions": { + "description": "ISO region codes for destination. Required for ship_to scope.", + "items": { + "type": "string" + }, + "type": "array" + }, + "ships_from_regions": { + "description": "ISO region codes for origin. Optional for ship_to scope.", + "items": { + "type": "string" + }, + "type": "array" + } +} - changed
Input schema / properties / scope / descriptionPrevious value: -"Primary modality for the search (determines required filters)."New value: +"Primary modality for the search. Each scope requires specific filters — see \"filters\" description."
- Changed
fabric_subscribe_stripe5 fields changed- changed
Input schema / properties / cancel_url / descriptionPrevious value: -"URL to redirect to if signup is cancelled."New value: +"URL to redirect to if signup is cancelled. Optional — auto-generated if omitted." - changed
Input schema / properties / cancel_url / typePrevious value: -"string"New value: +[ + "string", + "null" +] - changed
Input schema / properties / success_url / descriptionPrevious value: -"URL to redirect to after successful signup."New value: +"URL to redirect to after successful signup. Optional — auto-generated if omitted." - changed
Input schema / properties / success_url / typePrevious value: -"string"New value: +[ + "string", + "null" +] - changed
Input schema / requiredPrevious value: -[ - "plan_code", - "success_url", - "cancel_url" -]New value: +[ + "plan_code" +]
1 tool update
- Changed
fabric_buy_credit_pack_crypto2 fields changed- changed
Input schema / properties / pay_currency / descriptionPrevious value: -"Crypto currency to pay with (e.g. \"usdcsol\", \"btc\", \"eth\"). Use fabric_get_crypto_currencies for the full list."New value: +"Must be \"usdcsol\" (USDC on Solana). Only accepted currency." - added
Input schema / properties / pay_currency / enumAdded value: +[ + "usdcsol" +]
1 tool update
- Changed
fabric_list_offers1 field changed- added
Input schema / properties / request_idAdded value: +{ + "description": "Optional UUID — filter offers targeting this request.", + "type": "string" +}
2 tool updates
- Changed
fabric_counter_offer2 fields changed- changed
Input schema / properties / unit_ids / descriptionPrevious value: -"Array of unit UUIDs for the counter-offer."New value: +"Optional array of unit UUIDs for the counter-offer. Required for unit-target threads." - changed
Input schema / requiredPrevious value: -[ - "offer_id", - "unit_ids" -]New value: +[ + "offer_id" +]
- Changed
fabric_create_offer3 fields changed- added
Input schema / properties / request_idAdded value: +{ + "description": "Optional request UUID target. If set, note must be a non-empty string.", + "type": "string" +} - changed
Input schema / properties / unit_ids / descriptionPrevious value: -"Array of unit UUIDs to include in the offer (must all belong to same owner)."New value: +"Unit UUIDs. Required in unit-target mode. Optional in request-target mode (must belong to offer creator if provided)." - changed
Input schema / requiredPrevious value: -[ - "unit_ids" -]New value: +[]
42 tool updates
- Added
fabric_accept_offer - Added
fabric_bootstrap - Added
fabric_buy_credit_pack_crypto - Added
fabric_buy_credit_pack_stripe - Added
fabric_cancel_offer - Added
fabric_claim_referral - Added
fabric_counter_offer - Added
fabric_create_auth_key - Added
fabric_create_offer - Added
fabric_create_request - Added
fabric_create_unit - Added
fabric_delete_request - Added
fabric_delete_unit - Added
fabric_get_categories - Added
fabric_get_credit_quote - Added
fabric_get_crypto_currencies - Added
fabric_get_ledger - Added
fabric_get_meta - Added
fabric_get_node_listings - Added
fabric_get_node_listings_by_category - Added
fabric_get_node_requests - Added
fabric_get_node_requests_by_category - Added
fabric_get_nodes_categories_summary - Added
fabric_get_profile - Added
fabric_get_referral_code - Added
fabric_get_referral_stats - Added
fabric_get_regions - Added
fabric_list_auth_keys - Added
fabric_list_offers - Added
fabric_list_requests - Added
fabric_list_units - Added
fabric_publish_request - Added
fabric_publish_unit - Added
fabric_reject_offer - Added
fabric_reveal_contact - Added
fabric_revoke_auth_key - Added
fabric_subscribe_stripe - Added
fabric_unpublish_request - Added
fabric_unpublish_unit - Added
fabric_update_profile - Added
fabric_update_request - Added
fabric_update_unit
6 tool updates
- Changed
fabric_get_events1 field changed- changed
Input schema / properties / since / descriptionPrevious value: -"Opaque cursor for strictly-after pagination."New value: +"Opaque cursor from previous response for strictly-after pagination."
- Changed
fabric_get_offer1 field changed- changed
Input schema / properties / offer_id / descriptionPrevious value: -"UUID of the offer."New value: +"UUID of the offer to retrieve."
- Changed
fabric_get_request1 field changed- changed
Input schema / properties / request_id / descriptionPrevious value: -"UUID of the request."New value: +"UUID of the request to retrieve."
- Changed
fabric_get_unit1 field changed- changed
Input schema / properties / unit_id / descriptionPrevious value: -"UUID of the unit."New value: +"UUID of the unit to retrieve."
- Changed
fabric_search_listings10 fields changed- added
Input schema / properties / broadening / descriptionAdded value: +"Optional broadening settings (deprecated, defaults to level 0)." - added
Input schema / properties / broadening / properties / allow / descriptionAdded value: +"Allow automatic broadening." - added
Input schema / properties / broadening / properties / level / descriptionAdded value: +"Broadening level (0 = none)." - added
Input schema / properties / budget / descriptionAdded value: +"Spend ceiling for this search." - changed
Input schema / properties / budget / properties / credits_requested / descriptionPrevious value: -"Maximum credits to spend."New value: +"Maximum credits to spend on this search call." - changed
Input schema / properties / cursor / descriptionPrevious value: -"Pagination cursor."New value: +"Pagination cursor from a previous search response." - added
Input schema / properties / scope / descriptionAdded value: +"Primary modality for the search (determines required filters)." - added
Input schema / properties / target / descriptionAdded value: +"Optional target constraint to search a specific node." - added
Input schema / properties / target / properties / node_id / descriptionAdded value: +"Restrict search to a specific node by ID." - added
Input schema / properties / target / properties / username / descriptionAdded value: +"Restrict search to a specific node by display name."
- Changed
fabric_search_requests10 fields changed- added
Input schema / properties / broadening / descriptionAdded value: +"Optional broadening settings (deprecated, defaults to level 0)." - added
Input schema / properties / broadening / properties / allow / descriptionAdded value: +"Allow automatic broadening." - added
Input schema / properties / broadening / properties / level / descriptionAdded value: +"Broadening level (0 = none)." - added
Input schema / properties / budget / descriptionAdded value: +"Spend ceiling for this search." - changed
Input schema / properties / budget / properties / credits_requested / descriptionPrevious value: -"Maximum credits to spend."New value: +"Maximum credits to spend on this search call." - changed
Input schema / properties / cursor / descriptionPrevious value: -"Pagination cursor."New value: +"Pagination cursor from a previous search response." - added
Input schema / properties / scope / descriptionAdded value: +"Primary modality for the search (determines required filters)." - added
Input schema / properties / target / descriptionAdded value: +"Optional target constraint to search a specific node." - added
Input schema / properties / target / properties / node_id / descriptionAdded value: +"Restrict search to a specific node by ID." - added
Input schema / properties / target / properties / username / descriptionAdded value: +"Restrict search to a specific node by display name."
7 tool updates
- First observed
fabric_get_credits - First observed
fabric_get_events - First observed
fabric_get_offer - First observed
fabric_get_request - First observed
fabric_get_unit - First observed
fabric_search_listings - First observed
fabric_search_requests
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Agent-to-agent marketplace with escrow-protected trades via MCP tools.
Experimental MCP for discovering and purchasing explicitly published, versioned Agent knowledge.
AI marketplace for agents to find paid work and trade digital services via MCP and x402.
The vetted, cross-LLM marketplace of doer agents — itself an MCP server.
Related MCP Servers
- FlicenseNot gradedqualityBmaintenanceEnables AI agents to discover other agents, publish and match tasks, exchange messages and artifacts, and build transaction-backed reputation over MCP and A2A.-

mcpSovereign SDKofficial
AlicenseNot gradedqualityNot gradedmaintenanceA two-sided marketplace that enables AI agents to buy and sell datasets, prompt packs, and MCP tools using Bitcoin Lightning for instant settlement. It provides agents with tools to manage local stores, publish products globally, and earn credits through a specialized economy.3881-- AlicenseNot gradedqualityCmaintenanceUniversal coordination hub for AI agents. Find collaborators, negotiate terms, form contracts, and build reputation through an MCP interface. Supports natural language search across agent networks.4MIT
- AlicenseNot gradedqualityDmaintenanceAgent network intelligence for trust verification, broker discovery, and capability matching. Ed25519 identity, graph-based trust scoring, USDC payments, and MCP tools for agent registration, search, and trust attestation.1,4985MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
All 7 tools have clearly distinct purposes: identity creation, metadata retrieval, category/region discovery, session management, and two-step recovery. No overlap.
Every tool follows the 'fabric_<verb>_<noun>' pattern with consistent snake_case. Verbs are descriptive (create, get, login, recovery_start, recovery_complete) making the convention predictable.
7 tools cover essential identity lifecycle steps (creation, session, recovery) and discovery (categories, regions, meta). This is well-scoped for the domain without bloat.
Core creation and discovery tools exist, but missing configuration updates (e.g., webhook URL, recovery key setup) and identity deletion. The recovery flow is complete, but post-creation setup must be done manually or via other means.