AutEng MCP - Markdown Publishing & Document Share Links

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

With no annotations provided, the description carries full burden and discloses critical behavioral traits: authentication mechanism, temporal validation (5 min), single-use constraints on nonce, content size limits (100 KB), and default derivation logic for optional title. 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?

Well-structured with logical flow: purpose statement → authentication requirements → parameter details. Front-loaded with the core action. Length is appropriate given zero schema coverage and complex auth requirements, though the Args list is extensive.

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 high complexity (8 parameters, 7 required) and zero schema coverage, the description is substantially complete with auth protocol and validation rules documented. Missing explicit conflict behavior (what happens if path exists) and explicit sibling differentiation, but return values are covered by existing 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 has 0% description coverage (only types/titles). The Args section compensates comprehensively by documenting all 8 parameters with formats (0x... checksummed, 32 chars hex), examples (reports/q1.md), constraints (max 100 KB, must end with extension), and optionality rules.

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 (Create) and resource (document in agent's workspace) clearly. Distinguishes implicitly from siblings like delete, update, and publish through distinct action and scope, though it does not explicitly name alternative tools.

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

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

Provides clear prerequisites for usage: detailed EIP-191 wallet authentication flow including message format, timing constraints (5 min window), and nonce requirements. Lacks explicit sibling contrast (e.g., when to use vs update), but the auth guidelines constitute substantial usage context.

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?

No annotations provided, so description carries full burden. Exposes critical behavioral complexity by detailing EIP-191 auth mechanism (signature format, timestamp, nonce requirements). Deduct one point for not explicitly stating deletion is permanent/irreversible or describing failure modes (e.g., file not found behavior).

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

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

Excellent structure: single sentence purpose, auth requirement, cross-reference, and Args block. Every line delivers value. No redundancy despite needing to document 6 undocumented parameters.

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 6 required parameters with zero schema coverage, the description adequately compensates via Args documentation. Auth complexity is well-addressed. Minor gap regarding output behavior (deletion confirmation, error handling) though output schema exists to cover returns.

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 0% schema description coverage (titles only), the Args section comprehensively compensates by documenting all 6 parameters: format specs (0x... checksummed, 32 char hex), protocol details (EIP-191 signature structure), and semantic examples ('reports/q1.md'). Exceeds baseline expectations for zero-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?

Clear verb ('Delete') and resource ('document from the agent's workspace') establishes specific purpose. However, it does not explicitly distinguish from sibling 'auteng_docs_update' (modification vs removal) or indicate when deletion is preferred over updates.

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 prerequisite guidance ('Requires EIP-191 wallet signature auth') and useful cross-reference to sibling ('See auteng_docs_create for auth details'). Lacks explicit 'when to use vs alternatives' guidance contrasting deletion with update or archival 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?

No annotations provided, so description carries full burden. Discloses authentication mechanism details and prefix filtering capability. Missing side-effect details (though obvious for a list operation) and error handling behaviors.

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?

Uses structured docstring format with clear Args section. Appropriately sized given the need to document 6 parameters with 0% schema coverage. No redundant sentences.

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 6 parameters with complex auth requirements and existing output schema, the description provides sufficient information for correct invocation. Parameter documentation is comprehensive, though behavioral edge cases are not covered.

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 0%, requiring description to compensate. The Args section excellently documents all 6 parameters with formats (0x..., Unix timestamp, 32 char hex), examples (e.g. 'reports/'), and constraints (single-use nonce).

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 (List) + resource (documents) + scope (agent's workspace). Implicitly distinguishes from siblings like create/delete/update through the listing action, though it doesn't explicitly contrast with `auteng_docs_recent`.

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?

Specifies authentication prerequisite (EIP-191) and references sibling `auteng_docs_create` for auth details, providing necessary context. However, lacks explicit guidance on when to use this vs. `recent` or filtering capabilities compared to other list 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?

With no annotations provided, the description carries the full burden. It successfully discloses the authentication requirement (critical behavioral trait) and sort ordering ('newest first'), but omits rate limits, pagination edge cases, or explicit read-only safety guarantees given the presence of destructive sibling tools.

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?

Efficiently front-loaded: first sentence defines purpose, second states auth requirements, third describes return behavior, followed by the Args documentation. Zero wasted words; 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 existence of an output schema (which excuses detailed return value description) and the tool's simplicity (2 optional params), the description is complete. It appropriately emphasizes the 'public'/unauthenticated aspect to differentiate from siblings, though it could explicitly confirm this is read-only given the server contains destructive document operations.

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 0% schema description coverage (only titles 'Page' and 'Limit'), the description fully compensates by documenting both parameters inline, including critical constraints like the maximum value of 100 for limit and the default values, adding meaning entirely absent from 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 opens with a specific verb ('Browse') and clearly identifies the resource ('public recents feed of shared documents'), immediately distinguishing it from sibling tools like auteng_docs_list (likely private/user-specific) and the mutation operations (create/delete/update).

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 explicit 'No authentication required' provides crucial context that clearly distinguishes this tool from its siblings which likely require auth. However, it does not explicitly name alternatives or state when NOT to use this (e.g., when searching private documents).

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?

No annotations provided, yet description fully discloses critical behavioral traits: rate limiting (10 shares/wallet/day), authentication requirements (EIP-191 signature with specific message format), side effects (public exposure of document), and return value (shareable URL). Exemplary transparency for a state-modifying operation.

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?

Efficient multi-layer structure: 2-sentence value proposition header, constraint notifications, then structured Args block. Every sentence serves distinct purpose (capability, limits, auth, parameters). Slightly verbose due to necessity of compensating for zero schema descriptions, but no redundant information.

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

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

Comprehensive for a 7-parameter mutation tool: documents auth flow, rate limits, visibility constraints, and return value despite having output schema (which reduces burden). Cross-references sibling for recursive auth details rather than duplicating. Minor gap: doesn't describe error conditions or what happens if path doesn't exist.

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 0% (only titles), but description compensates comprehensively via Args block documenting all 7 parameters with semantic meaning: wallet_address (checksummed format), wallet_signature (EIP-191 with template string), wallet_nonce (32-char single-use constraint), path (example 'reports/q1.md'), and visibility (enum constraint). Critical format constraints (0x..., Unix seconds, hex string) are specified that schema omits.

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: verb 'Share' + resource 'document' + scope 'publicly' + output 'shareable URL'. Clearly distinguishes from siblings like auteng_docs_create (creation) and auteng_docs_list (read-only listing) by focusing on public distribution.

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?

Strong contextual guidance: references sibling 'auteng_docs_create for auth details' establishing tool relationships; documents rate limit (10/day) and visibility constraint ('only public in current version'). Lacks explicit negative guidance (when NOT to use vs other tools), but covers prerequisites well.

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?

With no annotations provided, the description carries full disclosure burden and succeeds: it reveals the EIP-191 auth requirement, the 100 KB content limit, single-use nonce constraint, and checksummed address requirement. Only minor gap is lack of detail on what happens if the path doesn't exist.

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?

Efficiently structured with a single purpose sentence, auth requirement note, sibling reference, and compact Args block. Every line delivers necessary information without redundancy; the front-loaded purpose allows immediate comprehension.

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 (mutation operation, 7 auth-heavy parameters, output schema exists), the description is complete. It covers operational scope, authentication mechanics, input constraints, and file path conventions. Output schema presence excuses lack of return value description.

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

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

Schema description coverage is 0%, but the Args section fully compensates by documenting all 7 parameters with specific formats (0x... checksummed, 32 chars hex, Unix timestamp), value constraints (max 100 KB), and syntax examples ('reports/q1.md'). This is exemplary 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?

The description opens with a specific verb ('Update') and clear resource ('existing document in the agent's workspace'), immediately distinguishing it from the 'create' sibling. It precisely scopes the operation to existing files rather than new ones.

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 the prerequisite of 'EIP-191 wallet signature auth' and references 'auteng_docs_create' for auth details, implying the sibling relationship. Clear that this targets existing documents (implied vs. create), but does not explicitly map when to use vs. delete or list siblings.

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?

With no annotations provided, the description carries full burden for behavioral disclosure. It states this creates 'publicly shareable' documents but doesn't specify what that means in practice (e.g., URL generation, access controls, or visibility implications). It mentions expiration capability but doesn't explain default behavior when expires_hours is null. Critical mutation aspects like whether this operation is idempotent or requires specific permissions are undocumented.

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 brief (two sentences) but the second sentence about backend proxying adds no user-facing value and wastes space. The first sentence is front-loaded with the core purpose, but overall structure could be improved by replacing implementation details with usage guidance.

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 mutation tool with no annotations, 3 parameters at 0% schema coverage, but with an output schema present, the description is moderately incomplete. The output schema will handle return values, but the description lacks crucial context about the mutation behavior, parameter meanings, and differentiation from sibling tools. It covers the basic 'what' but misses the 'how' and 'when'.

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 0%, so the description must compensate but provides no parameter information. It doesn't explain what 'markdown' content format is expected, what 'title' is used for, or how 'expires_hours' affects document lifetime. The three parameters remain semantically undocumented despite being critical to tool operation.

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

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

The description clearly states the verb ('publish') and resource ('markdown as a publicly shareable AutEng document'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like auteng_docs_create or auteng_docs_share, which might have overlapping functionality.

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

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

No guidance is provided on when to use this tool versus alternatives like auteng_docs_create or auteng_docs_share. The description mentions it 'proxies to backend endpoint' but this is technical implementation detail, not usage context. There's no mention of prerequisites, when-not-to-use scenarios, or comparisons with siblings.

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