Fabric Marketplace

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

Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds the specific action types but omits critical behavioral details: whether revoked keys are recoverable, that 'create' likely returns a secret that must be immediately saved, or rate limiting. Does not contradict 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?

Two sentences with zero waste. Front-loaded with purpose ('Manage API keys...') followed by usage hint. Every word earns its place; no redundant filler.

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 100% schema coverage and present annotations, the description meets minimum viability for tool selection. However, it lacks explanation of return values (e.g., whether 'create' returns the key string, what 'list' returns) and omits security warnings about handling created keys, which would be expected for a credential management tool.

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%, so baseline applies. The description redundantly lists the action enum values ('create', 'list', 'revoke') which reinforces the schema but adds no semantic depth regarding parameter relationships (e.g., that key_id is required only for revoke, or that label is only for create).

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?

States specific resource (API keys) and scope (authenticated node) with the general verb 'manage'. Lists specific actions (create/list/revoke) which helps distinguish from sibling auth tools like fabric_login_session. 'Manage' is slightly generic but clarified by the action examples.

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 no guidance on when to use this tool versus fabric_login_session or other auth mechanisms. Does not explain the workflow (e.g., that 'list' should be used before 'revoke' to obtain key_id). Only lists valid action values without contextual selection criteria.

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?

Far exceeds sparse annotations by disclosing: (1) 'No authentication required' (auth context), (2) 'auto-accepts the current legal version' (TOS behavior), (3) Detailed credit economics (free-first, milestone grants), (4) Return value structure ('Returns your node profile, API key, and initial credit grant') compensating for missing output schema, and (5) Critical security workflows (API key persistence, Ed25519 recovery key generation). No contradictions with annotations.

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

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

Information-dense and well front-loaded (purpose → usage → mechanics → economics → security). While lengthy, every sentence serves the agent's decision-making (especially credit economics and security warnings). Minor deduction only for the commerce context sentence which is slightly tangential.

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 initialization operation lacking an output schema. The description fully compensates by detailing return values, credit mechanics, legal auto-acceptance behavior, and mandatory cryptographic recovery procedures—leaving no critical gaps for an agent bootstraping a node identity.

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?

With 100% schema coverage, the baseline is 3. The description elevates this by adding workflow-critical context not present in the schema: instructing the agent to 'generate and store the matching Ed25519 recovery private key locally' and emphasizing immediate persistence of the returned API key—security requirements essential for correct invocation that raw parameter definitions omit.

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 a specific verb-resource-outcome triple ('Create a new Fabric node and receive an API key + 500 free credits') that precisely defines the scope. It clearly distinguishes this as the identity-initialization entry point versus operational siblings like fabric_create_inventory.

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 guidance: 'Call this once per participant identity, then persist and reuse' establishes the lifecycle pattern, while 'Do not call bootstrap for each unit, request, or offer' explicitly defines negative scope and directs the agent toward the correct sibling tools for subsequent operations.

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?

The description adds valuable behavioral context not present in annotations: it discloses the auto-publishing behavior ('Publish-ready payloads become public automatically') and cost model ('free (0 credits)'). These are critical operational details beyond the basic write/non-destructive hints in 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 efficiently structured in three sentences covering purpose, parameter semantics, and behavioral traits. The phrase 'in one tool' is slightly awkward but does not significantly detract from the otherwise tight composition.

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 complex 25-parameter tool, the description successfully highlights the critical distinctions (unit vs request), visibility rules, and cost. Given the comprehensive schema coverage and lack of output schema, it appropriately focuses on creation behavior and publishing logic.

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?

While the schema has 100% coverage, the description adds narrative context linking 'kind' values to business concepts (supply/listing vs demand/need) and emphasizes the publishing workflow. It elevates the raw schema definitions into actionable guidance.

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 inventory and explicitly distinguishes the two primary use cases: 'unit' for supply/listings versus 'request' for demand/needs. This semantic differentiation helps agents select the correct kind parameter and understand the tool's dual purpose.

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

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

It provides clear guidance on when to use draft versus published status ('unless publish_status=draft') and explains the two inventory kinds. However, it does not explicitly differentiate this from sibling fabric_update_inventory or indicate when to use create versus update operations.

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 idempotentHint=true, readOnlyHint=false, and destructiveHint=false, covering safety. The description adds no behavioral context about side effects (e.g., what happens after accepting—does it create a contract?), business rules, or state transitions.

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?

Brief two-sentence structure. However, the second sentence wastes space repeating schema enum values that could have been used for usage guidelines or behavioral context. Otherwise efficiently worded.

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?

Inadequate for a workflow-critical tool with 4 parameters. Missing workflow context (this is an offer resolution step), no mention of required preceding steps (fabric_get_offers), and no explanation of consequences for each action type despite being a decision point in a business process.

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?

With 100% schema description coverage, the schema already documents all parameters including the enum values and optionality rules. The description merely duplicates the enum values ('accept', 'reject', 'cancel') already present in the schema, adding no semantic depth.

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?

Clearly states the three possible actions (accept, reject, cancel) and the target resource (offer). However, it doesn't clarify how this differs from sibling tools like fabric_report_offer or fabric_start_purchase, which also relate to offer management.

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 only syntax guidance ('Use action=...') rather than usage guidance. Missing: prerequisites (e.g., offer_id source), when to use vs alternatives (fabric_start_purchase), and whether rejection is final.

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 crucial context beyond annotations: explains 'Soft-delete' nature (aligning with destructiveHint=false), and specifies visibility impact ('Removed from private inventory and public projections'). This behavioral detail about where the inventory disappears from is not captured in the structured 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?

Three sentences, zero waste: front-loaded with action and scope, followed by parameter guidance, ending with behavioral impact. Every clause earns its place without redundancy.

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

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

Complete for a 3-parameter deletion tool with good schema coverage. Covers ownership requirements, soft-delete semantics, and visibility effects. Could enhance by mentioning recovery implications or why idempotentHint=false, but sufficient given the tool's straightforward nature.

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?

With 100% schema description coverage, the schema already documents all parameters including kind enum values. The description reinforces the kind parameter values ('Set kind=unit or kind=request') but adds minimal semantic meaning beyond what the schema already provides. Baseline 3 is appropriate for high schema coverage.

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

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

The description clearly states 'Soft-delete inventory you own' — specific verb (soft-delete), resource (inventory), and scope (you own). It distinguishes from hard deletion and other inventory operations (create/update) through the soft-delete qualifier and ownership constraint.

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?

Implies prerequisites through 'inventory you own' and provides parameter guidance ('Set kind=unit or kind=request'), but lacks explicit when-to-use guidance versus alternatives like fabric_update_inventory or fabric_set_inventory_visibility. No explicit exclusions or prerequisites mentioned.

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by disclosing the specific view types available (particularly the non-obvious 'crypto_currencies' option), but doesn't address rate limits, data freshness, or pagination behavior beyond the schema.

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

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

Two sentences with zero waste. The first establishes the resource domain; the second provides the critical view parameter options. Every word earns its place and the information is 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?

Given the tool is read-only with comprehensive annotations and 100% schema coverage for its 4 parameters, the description provides sufficient context. No output schema exists, but the description doesn't need to explain return values beyond the view type hints.

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?

With 100% schema description coverage, the baseline is 3. The description repeats the enum values for the view parameter, which confirms the schema but doesn't add semantic meaning. It doesn't elaborate on the relationship between limit/cursor for pagination or provide examples.

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 'Read billing/credit data' with a specific verb and resource. It distinguishes from siblings (fabric_get_inventory, fabric_get_events, etc.) through the specific 'billing/credit' domain, though it doesn't explicitly contrast with them in the text.

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 lists the four valid view options ('balance', 'quote', 'ledger', 'crypto_currencies'), providing implicit guidance on available modes. However, it lacks explicit when-to-use guidance for selecting between views or prerequisites for using the session_token parameter.

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 already declare read-only/idempotent safety profile. Description adds valuable behavioral context: cursor-based pagination semantics ('strictly-after semantics'), opaque cursor nature, and specific event types returned. Does not mention rate limits 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?

Four sentences efficiently structured: purpose definition, event examples, usage guidance, and technical pagination semantics. Every sentence earns its place with zero 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?

Complete for a polling tool with no output schema. Covers domain (offer lifecycle), mechanism (cursor pagination), authentication context, and fallback usage scenario. Does not need to describe return values absent 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%, establishing baseline 3. Description adds semantic value by explaining the cursor pattern ('opaque cursor with strictly-after semantics') which reinforces the since parameter usage, and contextualizes session_token usage via 'authenticated node' reference.

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?

States specific verb 'Poll' with resource 'offer lifecycle events' and scope 'for the authenticated node'. Lists concrete event examples (offer_created, offer_accepted, offer_countered) that clarify the domain.

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 'Use this as the fallback when your runtime cannot receive webhooks', providing clear when-to-use guidance and implicitly contrasting with webhook-based alternatives among sibling 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?

Adds valuable context beyond annotations: specifies 'full canonical record' (indicating complete vs. partial data), 'you own' (ownership scope), and reinforces idempotent read behavior consistent with annotations. No contradictions with readOnlyHint/idempotentHint.

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, zero waste. Front-loaded with action and resource, followed immediately by critical parameter values and return value description. No filler or redundant text.

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?

Appropriate for a simple read operation with complete annotations. Mentions return value ('full canonical record') despite absence of output schema. Could explicitly acknowledge inventory_id requirement, but schema coverage compensates.

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?

With 100% schema coverage, baseline is 3. Description reinforces the enum semantics for 'kind' ('unit' for supply, 'request' for demand) but does not add meaning for inventory_id or session_token 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?

Clear specific verb ('Get') + resource ('inventory') with ownership scope ('you own'). The phrase 'Returns the full canonical record' effectively distinguishes this from fabric_list_inventory (which likely returns summaries/lists) and fabric_get_node_inventory (node-scoped).

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?

Implies single-record retrieval via 'full canonical record' and required inventory_id in schema, but lacks explicit when-to-use guidance contrasting with fabric_list_inventory or fabric_search. No mention of prerequisites like needing the inventory_id UUID.

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 crucial behavioral context beyond annotations: discloses that category drilldowns are 'credit-metered' (cost implication) and distinguishes between 'standard node inventory page' vs 'drilldown' behavior. Aligns correctly with readOnlyHint/idempotentHint 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?

Three sentences, zero waste. Front-loaded with purpose ('Inspect another node's public inventory'), followed by required parameter guidance, then optional parameter behavior. Every sentence 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?

Complete for a read-only inspection tool with good schema coverage. Captures the cost model (credit-metered) and view modes (standard vs drilldown). No output schema exists, but per instructions, description needn't explain return values.

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?

With 100% schema coverage (baseline 3), the description adds meaningful semantics by explaining the practical difference between 'listings' and 'requests' via example values, and clarifying the conditional logic for 'category_id' usage (omit for standard, provide for drilldown).

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?

States specific verb 'Inspect' and resource 'another node's public inventory'. The phrase 'another node' effectively distinguishes this from sibling tools like fabric_get_inventory (implied own inventory) and fabric_list_inventory.

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 parameter-level guidance: specifies valid values for 'kind' ('listings' or 'requests') and explains when to provide vs omit 'category_id' (drilldown vs standard page). However, lacks explicit comparison to sibling tools like fabric_get_nodes_categories_summary.

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), while the description adds critical operational constraints not in annotations: the 50-node batch limit and 'public nodes' scope restriction. No contradictions with annotations.

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

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

Single sentence that is front-loaded with the action and contains zero waste. Every clause earns its place: verb, resource, quantity limit, and scope.

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?

Adequate for a read-only batch operation given strong annotations and input schema coverage. The description covers the key batch constraint. Minor gap: doesn't hint at what fields comprise a 'category summary' given no output schema exists.

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?

With 100% schema coverage, the baseline is 3. The description references the '50' node limit which aligns with the node_ids parameter description, but doesn't add semantic details beyond the schema (e.g., doesn't explain the 'kind' enum or 'session_token' usage).

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 verb ('Get') and resource ('category summaries'), with specific scope ('up to 50 public nodes at once'). The batch size limit effectively distinguishes it from single-node sibling tools like fabric_get_node_inventory, though 'Get' is slightly generic.

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?

Implicitly provides batching constraints ('up to 50') which guides usage limits, but lacks explicit guidance on when to prefer this over fabric_get_categories or fabric_get_node_inventory, and doesn't mention handling for larger batches.

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 declare readOnlyHint=true and idempotentHint=true. The description adds valuable operational context about the dual-mode behavior (detail vs list views) and pagination support that annotations don't cover. No contradictions with annotation safety flags.

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 with zero waste. Front-loaded with the core action ('Read offer data'), followed immediately by the specific usage patterns. Every word earns its place; no filler or redundancy despite covering two distinct operational modes.

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 100% schema coverage and clear annotations, the description provides sufficient context for the two distinct usage modes (single vs. list retrieval). Adequately covers the 7-parameter complexity without needing to describe return values (no output schema present).

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?

Despite 100% schema description coverage (baseline 3), the description adds semantic value by grouping parameters logically: associating offer_id with detail view and role/cursor/limit with list view. This parameter-to-mode mapping isn't explicit in the individual schema field descriptions.

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 ('Read offer data') and resource (offers). It effectively distinguishes from sibling tools like fabric_write_offer and fabric_decide_offer by emphasizing the read-only nature and data retrieval purpose.

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

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

Provides explicit usage patterns mapping view modes to required parameters: 'view=detail with offer_id' for single offers versus 'view=list with role/cursor/limit' for paginated lists. Could improve by explicitly contrasting with fabric_write_offer for mutations, but clearly defines when to use each view mode.

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?

Adds valuable behavioral context beyond annotations by specifying return scope: 'Returns both draft and published records, excluding deleted.' This disclosure about soft-delete filtering and draft visibility is crucial for agent expectations and is not indicated in the readOnly/destructive 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?

Two sentences with zero waste: first establishes purpose, second combines parameter guidance with return behavior. Information is front-loaded and every clause earns its place. No redundancy with schema or annotations.

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 100% schema coverage and read-only annotations, the description successfully covers the essential behavioral specifics (draft/published/deleted filtering) that structured data cannot express. Adequately complete for a list operation without output schema, though mention of pagination behavior would be a nice addition.

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?

With 100% schema coverage, the baseline is 3. The description adds semantic value by explaining the business logic behind 'kind' values ('listings/resources' vs 'needs/wants'), reinforcing the schema description with concrete terminology that helps the agent map user intents to parameter values.

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 states specific verb 'List' with clear resource scope 'your own inventory', distinguishing it from sibling 'fabric_get_inventory' (singular retrieval) and 'fabric_search' (general search). The phrase 'your own' clarifies this is user-scoped rather than node-scoped like 'fabric_get_node_inventory'.

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 guidance on when to use each enum value for the 'kind' parameter ('unit' for listings/resources vs 'request' for needs/wants). However, lacks explicit guidance on when to use this tool versus 'fabric_get_inventory' for single-item retrieval or versus 'fabric_search' for broader queries.

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 already declare idempotentHint=true, but the description adds crucial behavioral detail: 'returns ok even if already revoked or missing.' This specific return value behavior helps agents handle error cases. 'Early' also adds temporal context not in 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?

Two sentences with zero waste. First sentence front-loads the action and target. Second sentence delivers the idempotency guarantee. 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?

For a single-parameter revocation tool with clear annotations, the description is complete. It covers the operation, idempotency safety, and return behavior. No output schema exists, but 'returns ok' sufficiently indicates the success pattern.

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%, establishing baseline 3. The description doesn't add parameter semantics beyond the schema (which links the token to fabric_login_session), but doesn't need to given the comprehensive schema description.

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 'Revoke' + resource 'MCP session token' + timing qualifier 'early'. The mention of 'MCP session token' clearly distinguishes this from sibling tools like fabric_auth_keys or fabric_bootstrap, and implicitly pairs it with fabric_login_session.

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 'early' qualifier implies proactive session termination, and idempotency behavior hints at safe usage patterns. However, it lacks explicit guidance on when to prefer this over natural expiry or whether alternatives exist for bulk revocation.

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 indicate idempotentHint=true and destructiveHint=false. Description confirms dual read/write nature matching readOnlyHint=false, but adds no details on partial update behavior, error conditions, or side effects 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?

Two sentences with no fluff. However, the second sentence merely restates enum values available in the schema, making it partially redundant rather than value-add.

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?

Adequate for a basic CRUD tool with good annotations and schema coverage, but misses opportunity to describe the scope of profile data manageable (6 optional update fields including webhooks and messaging handles). No output schema exists but description doesn't hint at return structure.

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%, establishing baseline 3. Description mentions the action parameter values but adds no semantic context beyond the schema (e.g., which fields are required for update vs get, or webhook URL format expectations).

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?

States specific verbs (read/update) and resource (profile). Distinguishes from siblings like fabric_login_session or fabric_get_billing_info by focusing on user profile data, though could specify what profile entails (email, webhooks, etc.).

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?

Only specifies the action parameter values ('get' or 'update') which duplicates schema enum information. No guidance on when to use read vs update, prerequisites, or how this relates to sibling tools like fabric_login_session.

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.

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

The description is consistent with annotations (mentions 'claim' implying mutation, aligning with readOnlyHint: false), but adds minimal behavioral context beyond what annotations provide. It does not explain side effects of claiming, return data structure, or rate limits.

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 two-sentence structure is efficient and front-loaded with no wasted words. However, extreme brevity leaves important behavioral questions unanswered, suggesting the conciseness may be excessive for the tool's functional complexity.

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 3-parameter tool with full schema coverage and annotations, the description meets minimum viability but lacks explanatory depth. It omits what each action returns (critical given no output schema) and doesn't clarify the referral workflow context.

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?

With 100% schema coverage, the baseline is 3. The description lists the action enum values but does not add semantic meaning beyond the schema (e.g., explaining what 'code' returns vs 'stats'). It merely echoes the enum values already present in the structured schema.

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

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

The description clearly identifies the resource (referral data) and the dual nature of operations (read/claim), distinguishing it from sibling inventory/auth tools. However, it could be more specific about what 'code' and 'stats' retrieval entails.

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 enumerates the valid action parameter values but provides no strategic guidance on when to use this tool versus alternatives, or prerequisites for claiming referrals. It states 'how' to invoke but not 'when' to select it.

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 idempotentHint=true, which the description reinforces with the business rule 'One report per side per offer.' It adds workflow context ('after contact reveal') not present in annotations. Could improve by describing downstream effects (e.g., investigation triggered).

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 totaling under 30 words with zero redundancy. Front-loaded with action and scope, followed by specific use cases, ending with critical constraint. Every sentence 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?

Given the tool's position in the offer lifecycle (evident from siblings like fabric_reveal_contact), the description adequately covers trigger conditions and constraints. Lacks only minor details about return behavior, which is acceptable given the idempotent annotation and 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?

With 100% schema coverage, baseline is 3. The description adds value by mapping the abstract enum values to concrete scenarios (e.g., 'no-shows' maps to 'no_show' in schema), providing semantic context for the 'reason' parameter beyond the structured definitions.

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 a specific verb ('Report') and clearly defines the resource ('failed or suspicious post-accept outcome'). It distinguishes itself from siblings like fabric_decide_offer and fabric_reveal_contact by specifying the 'post-accept' timing and 'after contact reveal' prerequisite.

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 lists four specific scenarios for usage (no-shows, unresponsive, refusal after accept, fraud) that map directly to the reason enum. Critically includes the constraint 'One report per side per offer,' providing clear guidance on invocation limits.

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 read-only, idempotent safety profile. Description adds substantial value beyond annotations: discloses return payload contents (email, phone, messaging handles), conditional behavior for note-only deals (settlement_guidance inclusion), and off-platform settlement context (wire/stablecoin rails). No contradictions with annotations.

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

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

Four sentences with zero waste: sentence 1 defines purpose, sentence 2 details return values, sentence 3 states availability constraints, sentence 4 handles edge case (note-only deals). Information density is high with logical flow from general to specific conditions.

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 despite lack of output schema. Description compensates by enumerating return fields (email, phone, handles) and special response behavior (settlement_guidance). Preconditions and deal-type variations are fully covered. Annotations provide safety context. Would benefit from output schema, but description adequately fills the gap.

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 detailed descriptions for both offer_id and session_token. Description does not redundantly explain parameter syntax, which is appropriate given complete schema documentation. Implies offer_id must reference a mutually accepted offer, reinforcing but not duplicating schema information.

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?

Opens with specific verb 'Reveal' + resource 'counterparty contact info' + scope condition 'after mutual acceptance'. Clearly distinguishes from sibling tools like fabric_decide_offer (negotiation phase) and fabric_write_offer (creation phase) by specifying this is a post-acceptance disclosure 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?

Provides explicit prerequisite condition: 'Only available when offer status is mutually_accepted and the counterparty has configured an email.' This clearly signals when to invoke the tool. Lacks explicit naming of alternatives (e.g., 'use fabric_get_offers first to check status'), but the state dependency provides clear contextual guidance for sequencing.

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?

The description adds crucial behavioral information not present in annotations: 'Search is credit-metered' discloses cost implications and side effects that justify the readOnlyHint=false annotation. It appropriately implies this is a billing-affecting operation despite being a search.

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 with zero waste: purpose statement, parameter guidance, and cost warning. Information is perfectly front-loaded and each sentence 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?

Given the tool's complexity (10 parameters, nested filter objects with scope-specific requirements) and lack of output schema, the description is minimally adequate. It relies heavily on the comprehensive schema (100% coverage) but doesn't address pagination behavior, credit calculation specifics, or return value structure.

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?

With 100% schema description coverage, the baseline is 3. The description adds value by explicitly mapping kind='listings' to 'supply' and kind='requests' to 'demand', providing semantic context beyond the raw enum values in the schema.

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

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

The description clearly states the tool searches the marketplace and explicitly distinguishes between supply (listings) and demand (requests), which is domain-specific and useful. However, it doesn't explicitly differentiate from sibling retrieval tools like fabric_get_inventory or fabric_list_inventory.

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 guidance on using the kind parameter to switch between searching supply vs demand. However, it lacks explicit guidance on when to use this search tool versus sibling retrieval tools (e.g., 'use this for broad queries, use get_inventory for specific ID lookups').

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?

The description adds valuable cost information ('Free (0 credits)') not present in annotations. It aligns correctly with annotations (idempotent toggle operations, non-destructive). It does not contradict the idempotentHint=true or readOnlyHint=false 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?

Three sentences, each earning its place: purpose declaration, parameter instruction, and cost disclosure. No redundant words. Front-loaded with the core action. Excellent information density.

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 100% schema coverage, clear annotations, and no output schema to document, the description is nearly complete. Minor gap: it does not explain the business semantics of 'publish' (visible to marketplace) versus 'unpublish' (hidden), which would help distinguish from deletion.

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?

With 100% schema description coverage, the baseline is 3. The description reinforces the schema by explicitly listing the enum values for 'action' and mentioning 'kind' and 'inventory_id', but adds minimal semantic depth 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 clearly states the specific action (publish/unpublish) and resource (inventory). It effectively distinguishes from siblings like fabric_update_inventory (general field updates) and fabric_delete_inventory (removal) by focusing specifically on visibility toggling.

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 parameter values (action="publish" or action="unpublish") and cost information (0 credits), but lacks guidance on when to choose 'unpublish' versus 'delete', or when to use this tool versus fabric_update_inventory for visibility changes.

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 indicate this is a non-read-only (write), non-idempotent operation. The description adds context that Stripe and crypto payment methods are supported, but fails to disclose what 'starting' entails (e.g., returns checkout URL, creates pending transaction, triggers immediate charge) or side effects beyond the annotations.

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

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

Extremely concise at two sentences. The second sentence front-loads critical enum values for the required parameter, though this duplicates schema information. No wasted words, but slightly too terse for a financial transaction tool.

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 this is a 7-parameter purchase initiation tool with no output schema, the description omits crucial behavioral context: what the tool returns (checkout URL? session ID?), whether funds are immediately captured, and how to complete the purchase flow. The 100% schema coverage handles inputs, but the description must compensate for the missing 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?

With 100% schema description coverage, the schema already fully documents all 7 parameters including enum values and types. The description repeats the purchase_kind enum values without adding inter-parameter dependencies (e.g., plan_code only applies to subscription_stripe) or format constraints beyond what the schema 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?

States 'Start a purchase flow' with specific purchase_kind options (credit_pack_stripe, subscription_stripe, credit_pack_crypto), clearly indicating this initiates payment transactions. Distinguishes from sibling tools like fabric_get_billing_info by describing a write operation, though 'flow' is slightly vague about the exact mechanism.

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?

Lists the three valid purchase_kind values, implicitly guiding selection among purchase types. However, lacks explicit guidance on when to use this vs. siblings like fabric_get_billing_info or prerequisites such as authentication requirements.

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?

The description adds valuable context about optimistic concurrency (If-Match) that supplements the annotations (readOnlyHint: false, destructiveHint: false). However, it fails to mention the non-idempotent nature of the operation (idempotentHint: false in annotations) or explain error behaviors, return values, or side effects given the lack of 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?

The description consists of two efficient sentences with zero waste. The first establishes the operation (Patch inventory), and the second immediately front-loads the critical constraint (row_version requirement). Every word earns its place with no redundant fluff.

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 tool's high complexity (27 parameters, mutation operation, no output schema), the description covers the minimum viable information (operation type + concurrency requirement). However, it misses opportunity to explain the fetch-then-update workflow, enumerate which fields are commonly patched, or describe success/failure responses that would help an agent debug invocation errors.

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?

With 100% schema description coverage, the baseline is 3. The description elevates this by adding crucial semantic context that row_version is used for 'optimistic concurrency (If-Match)', explaining the parameter's purpose beyond the schema's literal description. It also highlights the 'kind' parameter as a key discriminator.

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 specific verb 'Patch' and resource 'inventory', clearly indicating a partial update operation. However, while 'by kind' references the required parameter, it doesn't explain the distinction between 'unit' and 'request' kinds, nor does it differentiate from sibling update tools like fabric_set_inventory_visibility.

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 crucial prerequisite guidance by stating that row_version from the latest payload is required for optimistic concurrency, implying a read-before-write pattern. However, it lacks explicit when-to-use guidance comparing this to fabric_create_inventory or fabric_delete_inventory, and doesn't mention what happens if the row_version mismatches.

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 write-operation status (readOnlyHint: false, idempotentHint: false). Description adds minimal behavioral context beyond this, omitting details about offer state transitions, side effects, or TTL expiration behavior. No contradictions with annotations.

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

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

Two sentences, zero waste. Front-loaded with core purpose, followed immediately by parameter logic. Every word earns its place.

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

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

Adequate for a tool with 8 parameters and dual modes given the comprehensive schema documentation. However, lacks workflow context (e.g., relationship to fabric_get_offers for retrieval before countering) and omits return value discussion despite no 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%, establishing baseline 3. Description highlights the critical action/offer_id relationship but does not add semantic depth beyond schema definitions (e.g., doesn't explain what 'unit_ids' represent or session_token auth flow).

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?

States specific verbs ('Create or counter') and resource ('offer'), clearly distinguishing from sibling tools like fabric_get_offers (read) and fabric_decide_offer (decision). The dual-mode purpose is explicit.

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 internal logic for the action parameter ('Use action=create for a new offer or action=counter with offer_id'). Lacks explicit comparison to workflow siblings (e.g., when to use fabric_decide_offer vs this tool), but the action guidance is specific.

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