Fabric Marketplace

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

Annotations cover basic hints (non-read-only, non-destructive, etc.), but the description adds valuable context beyond that: it discloses the free credit grant (500 credits), specifies that no authentication is required, outlines post-creation steps (persist data, configure recovery and webhook), and warns about the irreversible nature of identity creation. No contradiction with annotations.

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

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

The description is front-loaded with the core purpose and key constraints, followed by usage guidelines and post-creation steps. Most sentences earn their place, though it could be slightly more streamlined by integrating some details (e.g., combining authentication and credit info).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (identity creation with side effects) and lack of output schema, the description does well by detailing return values (node profile, API key, credits, guidance) and critical post-actions. However, it could briefly mention error cases or rate limits for full completeness.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description does not add significant meaning beyond the schema, such as explaining parameter interactions or usage nuances. It mentions persistence of node.id + api_key post-creation but doesn't directly relate to input parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Create a new Fabric participant identity') and resource ('node'), distinguishing it from siblings like fabric_login_session (for authentication) and fabric_recovery_* tools (for recovery). It explicitly notes this is not a credential refresh tool, preventing confusion with similar operations.

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 guidance on when to use this tool ('Do not use this if the participant already has a node') and when to use alternatives ('use fabric_login_session when headers are unavailable, or use recovery if the API key is lost'). It also mentions prerequisites ('No authentication required'), making it highly actionable.

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

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

Annotations already cover read-only/idempotent/destructive hints, so description adds valuable complementary context: authentication requirements and specific payload structure (IDs, slugs, names, descriptions, examples) that would normally appear in an output schema.

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

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

Two dense sentences with zero redundancy. First sentence defines operation and return payload; second covers auth prerequisites and integration guidance. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Compensates adequately for missing output schema by enumerating return fields. Covers auth and integration patterns relevant to the fabric ecosystem. Could be enhanced with pagination or caching behavior details, but sufficient for a simple registry fetch.

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?

Zero parameters present, establishing baseline score of 4 per scoring rules. Description appropriately focuses on output semantics rather than inventing parameter documentation.

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?

Uses specific verb 'Get' with clear resource 'category registry' and enumerates exact return fields (IDs, slugs, names, descriptions, examples). Distinguishes from sibling fabric_get_nodes_categories_summary by emphasizing 'full' registry versus summary data.

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?

Provides explicit prerequisite 'No authentication required' and usage context 'Use category IDs when creating units/requests' linking to dependent workflows. Lacks explicit mention of alternative tools like fabric_get_nodes_categories_summary for when summaries suffice.

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

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

Annotations cover safety profile (readOnly, idempotent). Description adds crucial behavioral context not in annotations: 'No authentication required' and specifics of returned metadata (category/docs/legal URLs), helping the agent understand what data to expect.

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 highly efficient sentences. First sentence front-loads the return payload specifics. Second sentence covers auth requirements and usage timing. Zero waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter metadata tool, description compensates for missing output_schema by enumerating expected return fields (legal version, API version, URLs) and providing clear workflow positioning. Would be 5 with explicit error condition notes or rate limits.

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?

Zero parameters (baseline 4 per rules). Schema is empty object with additionalProperties=false, fully described by structure. Description appropriately adds no redundant parameter documentation.

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?

Specific verb 'Get' + resource 'Fabric service metadata' with detailed payload specifics (legal version, API version, URLs). The phrase 'before bootstrap' clearly distinguishes it from the fabric_bootstrap sibling, establishing a discovery-phase role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use ('before bootstrap') and prerequisites ('No authentication required'). Lacks explicit 'when not to use' or named alternatives, but the temporal positioning relative to bootstrap provides clear contextual guidance.

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

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

Adds valuable behavioral details beyond annotations: explicitly states 'No authentication required' and describes the return format (ISO 3166-1/2 codes with examples 'US', 'US-CA'), compensating for the lack of output schema.

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

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

Three sentences, zero waste: sentence 1 establishes purpose+scope, sentence 2 states auth requirements, sentence 3 documents return format. Perfectly front-loaded and dense with essential 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?

Comprehensive for a zero-parameter lookup utility: covers purpose, auth constraints, and return value structure (with format standards and examples) despite lack of output schema. Annotations cover safety profile (readOnly, idempotent).

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?

Zero parameters with 100% schema coverage (trivially). Description correctly implies no inputs are needed through the declarative 'Get' construction. Baseline 4 as per zero-parameter rule.

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?

Excellent specificity: 'Get supported region codes' provides clear verb+resource, and 'for search filters and scope fields' establishes clear scope that distinguishes this from sibling tools like fabric_get_categories or fabric_get_events.

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?

Provides clear context that these codes are intended 'for search filters and scope fields,' indicating when to use the tool. Lacks explicit 'when not to use' or alternative tool names, but the functional context is sufficient for selection.

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

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

Annotations declare non-readonly (mutation) and non-idempotent hints. Description adds 'short-lived' qualifier (lifetime behavior) and specific runtime constraint context. 'No authentication required' is slightly confusing given the api_key parameter, but likely means 'no existing session required.' Adds moderate value beyond structured fields.

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?

Three sentences, zero waste. Front-loaded with core action (create token), followed by usage condition, then auth prerequisite. Each sentence earns its place with distinct, non-repetitive 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?

Tool creates session state (annotations confirm mutation) but no output schema exists to describe the returned token structure. Description states a token is created but doesn't hint at the return format or that subsequent tools will use this session. Adequate but not comprehensive given lack of output schema.

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% with complete description of api_key ('Fabric API key from bootstrap or key management'). Description mentions the api_key implicitly ('from an API key') but doesn't add syntax constraints or format details beyond schema. Baseline 3 appropriate when schema is comprehensive.

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?

Clear specific verb ('Create') + resource ('short-lived MCP session token') + input source ('from an API key'). Distinguishes from sibling 'fabric_logout_session' (likely the inverse operation) and 'fabric_auth_keys' (manages keys vs consumes them).

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?

Explicit conditional usage provided: 'Use this when your MCP runtime cannot reliably set Authorization headers.' Identifies the specific technical constraint triggering use. Minor gap: doesn't explicitly mention the alternative (direct header auth) or that this establishes session state for subsequent calls.

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

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

Annotations establish safety profile (readOnlyHint=false confirms write operation). Description adds critical behavioral context: 'Returns a new API key' explains the mutation result, and 'No authentication required' discloses an unusual auth pattern not evident in annotations. No contradictions.

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

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

Three sentences, front-loaded with purpose ('Complete account recovery'), followed by output and auth requirements. Zero waste. Efficient structure.

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?

No output schema exists, but description compensates by stating 'Returns a new API key'. Annotations present. Parameters fully documented in schema. Minor gap: could mention this is the final step in recovery workflow.

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 has 100% description coverage with detailed type info (Ed25519, hex/base64, reference to fabric_recovery_start). Description only implicitly references parameters ('providing the signed challenge'), adding no syntax/format details beyond schema. Baseline 3 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?

Description uses specific verb 'Complete' with resource 'account recovery' and clearly distinguishes from sibling 'fabric_recovery_start' (implied by 'Complete' vs 'Start'). Explicitly states it 'Returns a new API key', clarifying the output.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

States prerequisite 'No authentication required' which differentiates it from authenticated endpoints. However, lacks explicit workflow guidance on when to use vs 'fabric_recovery_start' (though parameter schema mentions it, the main description doesn't explicitly sequence the tools).

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

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

Annotations only indicate non-read-only/non-destructive. Description adds substantial behavioral context: returns 'challenge_id', requires Ed25519 cryptographic signing, specifies 'No authentication required' (critical for a recovery endpoint), and clarifies the two-step flow structure.

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?

Four efficient sentences with zero redundancy. Front-loaded with the condition (lost API key), followed by prerequisites, return value/next steps, and auth requirements. Each sentence conveys distinct mandatory 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?

Comprehensive for a complex cryptographic recovery flow. Compensates for missing output schema by documenting the return value (challenge_id) and the full multi-step workflow. Deducting one point only because it omits failure modes (e.g., what happens if recovery_public_key was never set).

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 has 100% description coverage for node_id. Description references the parameter but does not add semantic detail beyond the schema's explanation ('from your original bootstrap response' mirrors schema). Baseline 3 appropriate for high-coverage schemas.

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?

Specific verb-resource combination ('Start account recovery') clearly identifies the operation. Distinguishes itself from sibling tools by positioning within the recovery workflow (vs. fabric_bootstrap which creates the node initially, vs. fabric_recovery_complete which finishes the process).

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?

Excellent explicit constraints: when to use ('if you lost your API key'), prerequisites ('node_id from original bootstrap', 'recovery_public_key set at bootstrap'), and explicit next-step alternative ('call fabric_recovery_complete').

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