AutEng MCP - Markdown Publishing & Document Share Links

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

The description discloses the EIP-191 signature authentication requirement, exact message format, timestamp validity window, nonce constraints, content size limit, and path extension requirement. This is substantial behavioral context in the absence of annotations, fully carrying the burden.

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 organized with a one-sentence purpose, a concise auth block, and a bulleted arg list. The parameter details are necessary because the schema lacks descriptions, so the length is justifiable and every sentence adds value.

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 (8 parameters, authentication), the description is thorough: it covers auth flow, constraints, and all parameters. An output schema exists, so return semantics are not needed. The description is sufficiently complete for an agent to invoke the tool correctly.

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

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

The schema has no property descriptions (0% coverage), but the description thoroughly documents every parameter with format details (e.g., checksummed address, Unix timestamp, 32-char nonce, max 100KB content, path extension requirement). This completely compensates for the schema gap.

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 clear statement: 'Create a document in the agent's workspace.' This specific verb+resource combination distinguishes it from sibling tools like delete, list, share, and 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 purpose statement implies when to use the tool, and the detailed authentication requirements provide clear usage context. However, it does not explicitly compare against alternatives like update or publish_markdown.

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, the description carries the burden of disclosing behavior. It mentions EIP-191 wallet signature auth and the signature format, which is useful. However, it does not explicitly state that deletion is permanent, what happens on failure, or any side effects. Some key behavioral details are left implicit.

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 concise and front-loaded with the action, followed by the auth note and a parameter list. No filler or redundant content, and every part earns its place, though the parameter list is necessarily detailed.

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 6-parameter deletion tool with no annotations and an output schema, the description covers the essential purpose, auth requirements, and all parameter semantics. It also points to auteng_docs_create for auth details, which is helpful. It doesn't describe return values, but the output schema presumably does. Overall, fairly complete for selecting and invoking the 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?

The input schema has 0% description coverage, but the description compensates by explaining each parameter in detail: wallet_address as checksummed address, wallet_signature as EIP-191 signature with a specific format, wallet_timestamp as Unix seconds, wallet_nonce as a single-use random hex string, and path with an example. This adds significant meaning beyond 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 'Delete a document from the agent's workspace' with a specific verb and resource, and distinguishes this from sibling tools like auteng_docs_create, auteng_docs_update, and auteng_docs_share.

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 does not explicitly say when to use this tool vs alternatives or when not to use it. It provides an auth prerequisite, but no direct guidance on choosing delete over update or other actions. Usage is implied by the 'delete' verb.

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 are provided, so the description carries the burden of behavioral disclosure. It explicitly requires EIP-191 wallet signature auth, a critical non-obvious behavior, and lists all auth-related parameters. It does not explicitly state read-only, but 'list' implies a non-destructive operation. The prefix filter behavior is also disclosed.

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 compact and front-loaded with the primary purpose, followed by the auth requirement and a straightforward Args list. No redundant or filler text. Every sentence adds value, and the structure is scannable.

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 presence of an output schema, the description need not explain return values. It covers the tool's core purpose, auth requirements, and all parameters. It does not mention limitations like pagination or ordering, but for a straightforward list tool, the description is sufficiently complete for an agent to select and invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It does so fully by explaining each parameter: wallet_address format, wallet_signature structure, wallet_timestamp unit, wallet_nonce uniqueness constraint, agent_display_name purpose, and prefix filter with an example. This adds significant meaning beyond the bare 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's action: 'List documents in the agent's workspace.' This specifies a verb (List) and a resource (documents in the agent's workspace), distinguishing it from siblings like auteng_docs_recent (which likely lists recent documents) and other mutation tools. The scope is unambiguous.

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 context: it lists documents in the workspace, and the optional prefix filter hints at usage for organizing or filtering. It does not explicitly name alternatives or exclusions, but the list action is self-evident. It also cross-references auteng_docs_create for auth details, which indirectly aids usage.

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 are present, so the description carries full burden. It discloses authentication requirements, return content, ordering, and pagination behavior. It doesn't explicitly say 'read-only' or mention failure modes, but for a simple feed, it's transparent enough.

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 and front-loaded: first sentence states purpose, second sentence covers behavior, then a clean argument list. Every sentence earns its place with no 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?

With an output schema present, the description correctly focuses on inputs and behavioral context. It covers scope, ordering, pagination, and authentication, making it fully sufficient for an agent to invoke the tool correctly.

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

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

Schema coverage is 0%, so the description must compensate. It fully explains both parameters: 'page' as page number with default, 'limit' as items per page with default and max (100). This adds meaning beyond the raw 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 uses the specific verb 'Browse' and clearly identifies the resource as 'public recents feed of shared documents', distinguishing it from siblings like create, delete, update, share, and list. The scope is unambiguous: recently shared public documents.

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 context: public feed, no auth required, and newest-first ordering. It does not explicitly name alternatives or state when not to use, but the 'recents' focus inherently differentiates it from other doc tools, making the intended use evident.

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 are present, but the description discloses rate limiting (10 per day), EIP-191 signature requirement, and visibility constraint (only 'public'). This goes beyond the schema and provides crucial operational context.

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

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

The description is compact with a brief introduction, rate limit and auth warnings, and a structured arg list. Every sentence serves a purpose.

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

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

With an output schema present, the description doesn't need to explain return values. It covers auth, rate limits, and all parameter semantics, making it sufficiently complete for invocation.

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 zero parameter descriptions, so the description fully compensates with detailed semantics: wallet fields specify format and purpose, path includes an example, and visibility notes allowed value. This adds significant meaning.

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 'Share a document publicly' and notes it returns a shareable URL. Distinguishes from sibling tools (create, delete, list, recent, update, publish_markdown) through the specific 'share' action.

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 context of public sharing and references auteng_docs_create for auth details, implying how to set up authentication. Does not explicitly list when-not-to-use or alternative tools, but the purpose is clear enough.

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 available, the description carries the burden. It discloses the auth requirement ('Requires EIP-191 wallet signature auth') and adds some behavioral constraints (single-use nonce, max 100 KB content, existing document). However, it does not describe side effects, error behavior, or whether the update overwrites content entirely, leaving gaps in transparency.

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 well-structured with a clear first sentence, a brief auth note, and a formatted args list. It avoids redundancy and each line provides necessary information, though the list is necessarily long due to 7 parameters. Earns a high score for clarity and organization.

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 has 7 parameters and no annotations, the description covers all required inputs with context (auth format, path example, content limit). Some aspects like the exact workspace root or behavior when the path doesn't exist are omitted, but the presence of an output schema reduces the need to describe return values. The description is sufficiently complete for an agent to invoke the tool correctly in most cases.

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 compensates fully. Every parameter is explained with format specifics: wallet_address is checksummed, wallet_signature format includes the exact string pattern, wallet_timestamp is Unix seconds, wallet_nonce is 32-char single-use hex, and content has a size limit. This adds substantial meaning beyond the bare string types 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 'Update an existing document in the agent's workspace' with a specific verb and resource. It also implicitly distinguishes from siblings by emphasizing 'existing' (vs create) and the workspace context, making it easy to identify which operation to invoke.

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?

Usage is implied: use this to update an existing document. It provides a prerequisite (EIP-191 auth) and points to auteng_docs_create for auth details, but does not explicitly state when to use this tool versus others (e.g., when to choose create or delete). No explicit exclusions are given.

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?

There are no annotations, so the description carries the full burden. It mentions 'publicly shareable' and states it proxies to a backend endpoint, but does not disclose side effects (e.g., whether a document is created or overwritten), authentication requirements, rate limits, or the lifespan of the published document. The endpoint line adds no behavioral value.

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 only two sentences, and the first sentence is directly useful. The second sentence, 'Proxies to backend endpoint: POST /api/tools/docs/publish-markdown/', is an implementation detail that is unlikely to help an agent decide to use the tool, but it is not bloated. Overall, it is concise and front-loaded, though the second sentence could be removed.

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 has 3 parameters, no annotations, and an output schema, the description is too sparse. It does not explain the relationship to sibling tools, the consequences of publishing, or what happens to the document after publishing. The output schema likely covers return values, but the description misses critical usage context and behavioral details.

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 for parameter meaning. It only hints that 'markdown' is the content to publish, but says nothing about the 'title' or 'expires_hours' parameters. The schema provides names and types, but the description adds little semantic context, especially for optional parameters that affect behavior.

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 what the tool does: 'Publish markdown as a publicly shareable AutEng document.' The verb 'publish' is specific, the resource (markdown) is identified, and the outcome (publicly shareable document) is described. This distinguishes it from sibling tools like auteng_docs_create or auteng_docs_share, which likely create or share existing documents.

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 no explicit guidance on when to use this tool versus the sibling tools. It does not mention alternatives, exclusions, or prerequisites. The only implicit usage is that it is for publishing markdown, but that is not enough to guide an agent in choosing between this and auteng_docs_create or auteng_docs_share.

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