monappamoi

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains that the app will appear in list_my_apps and can be managed without the token, which is useful, but it does not cover edge cases like invalid tokens, reversibility, or side effects beyond the visible outcome.

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

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

The description is two sentences, front-loaded with the action, and every clause adds useful information. No redundant or filler content.

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

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

For a simple tool with one parameter and no output schema, the description is quite complete. It specifies the action, the prerequisite (token), and the post-condition (app appears in list_my_apps). Minor gaps like authentication context or failure handling are not critical for this simple operation.

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

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

The input schema already provides 100% coverage of the single parameter, including its token format (maam_app_…). The description adds little beyond restating that the token is secret, so it does not significantly enhance the schema's 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?

The description uses a specific verb ('Rattache') and identifies the resource (an app published anonymously) and the mechanism (via its secret token). It clearly distinguishes itself from sibling tools like publish_app, delete_app, or list_my_apps by stating the outcome of the operation.

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 explicitly states when to call the tool: when the user wants to 'récupérer' or 'rattacher' an app published without an account. It provides clear usage context, though it does not explicitly mention when not to use it or name alternative tools for other scenarios.

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 transparency burden. It discloses permanent removal, URL invalidation, and the need for user confirmation. It does not detail data cascade or ownership requirements, but the core destructive behavior is transparent.

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 three short sentences, each adding value: permanence, effect on URL, and user confirmation. No fluff or redundant repetition.

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 destructive delete operation, the description covers permanence, side effect, and confirmation step. It does not mention authentication/ownership details or what happens to associated data, but these are secondary for the core action.

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 50%: the 'secret_token' parameter has a description in the schema, but 'slug' has none. The tool description adds no parameter-specific meaning, relying on schema and parameter names, which are adequate but not enriched.

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

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

The description uses a specific verb and resource: 'Retire définitivement une app de la plateforme' clearly indicates permanent deletion. It also clarifies the consequence ('Son URL cessera de fonctionner'), distinguishing it from sibling tools like update_app.

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 that the operation is permanent and destructive, and explicitly instructs to 'Demandez confirmation à l'utilisateur avant d'appeler cet outil.' It does not mention alternative tools, but the deletion intent is unmistakable.

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 clearly describes a read operation (returns metadata) and discloses specific output fields and the requirement that the app is 'published.' No side effects are indicated, which is appropriate for a read tool, and the description adds useful context beyond what a bare schema would provide.

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

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

The description is a single concise sentence that front-loads the action ('Renvoie') and clearly lists the metadata fields. No filler or redundant information; it earns its place entirely.

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

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

For a simple metadata retrieval tool with no output schema, the description is largely complete: it states the resource and the returned fields. The only minor gap is not explicating the need for secret_token for private apps not owned by the configured API key, but this is a parameter-level detail rather than a tool-level behavioral requirement.

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 description coverage is only 50% (slug has no description; secret_token has a schema description). The tool description does not explain the slug parameter or the role of secret_token, so it fails to compensate for the gap. Since slug is required and undocumented in both schema and description, the agent lacks necessary semantic 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?

The description 'Renvoie les métadonnées d'une app publiée (URL, titre, taille, dates de création et de mise à jour)' uses a specific verb ('Renvoie' returns) and clearly identifies the resource (metadata of a published app) with concrete fields. It distinguishes from sibling get_app_data, which likely returns the app's stored data rather than metadata.

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

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

The description implies usage when metadata is needed, but it provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like get_app_data. The context is clear but lacks exclusions or alternative recommendations.

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 full burden. It discloses behavior beyond simple reading: it works on locked apps if the owner token or API key is provided, and clarifies the lock only affects visitors. It does not mention side effects (like mutation), but as a read operation, the absence is acceptable. It could mention return size limits or pagination but is still strong.

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, both dense with value. The first sentence states the core function, the second adds usage guidance and auth details. No fluff, perfectly 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?

For a read tool with no output schema, it specifies the return is a JSON document. It explains when to use it and auth nuances. It could describe the document structure or mention that it returns user-generated data, but given dynamic data, this is adequate. It fully prepares an agent 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?

The description adds context to secret_token by explaining its role for locked apps and that the owner token or API key suffices. For slug, it implies it identifies the app, which is straightforward. With schema coverage at 50%, the description compensates moderately by clarifying the auth scenario.

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 returns the JSON document saved by app users, using a specific verb and resource. It distinguishes itself from siblings like get_app (metadata) and set_app_data (write), and adds depth by noting it works on locked apps.

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 advises calling this tool before evolving an app that saves data to understand the actual structure. Also clarifies it works on locked apps with owner credentials, providing clear when-to-use context without needing to contrast with 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?

The description frames the tool as an informational guide using 'Explique comment' (explains how), which implies a read-only, non-destructive operation. It details the topics covered but does not explicitly state the response format or that it is a reference document. The guide's French language is implied by the description, but not explicitly stated. Since no annotations are provided, the description carries the full behavioral disclosure burden, and this is largely met.

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

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

The description is two concise sentences. The first sentence enumerates the guide's content, and the second gives usage guidance. There is no filler or redundant information; every phrase 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?

For a zero-parameter documentation tool, this description fully covers what the tool does and when to use it. The lack of an output schema is acceptable since the guide is informational; the description sufficiently tells the agent what to expect without needing a detailed return format.

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

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

The tool has zero parameters, so the schema is trivially complete. The description does not need to explain parameters, and any missing information is not applicable. This aligns with the baseline for zero-parameter tools.

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 explains what the tool does: it provides a guide on writing an app, including data storage locations, persistence patterns, and how to evolve an app without breaking user data. This is specific and distinct from sibling tools (which are actions like publish_app, update_app, etc.), making the purpose unmistakable.

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 explicitly states when to use the tool: 'À lire avant de publier une app qui enregistre quelque chose, et avant tout update_app qui change la structure des données.' It references sibling tools (update_app) for specific scenarios, providing clear timing and alternatives.

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 full responsibility. It describes the tool as listing published apps, implying a read-only operation. However, it doesn't disclose response format, authentication requirements, or potential differences in behavior (e.g., whether unpublished apps are excluded). The verb 'Liste' conveys safety, but additional context is lacking, so a score of 3 is appropriate.

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

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

The description is two sentences long, with the primary purpose front-loaded in the first sentence and usage guidance in the second. Every sentence adds value with no redundancy.

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

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

Given the tool has no parameters or output schema, the description provides sufficient context: it states the resource scope (published apps, user account) and illustrates common use cases. It doesn't explicitly enumerate return fields, but the mention of 'retrouver l'adresse' implies the response includes app identifiers/addresses, which is adequate for this simple list 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 tool has zero parameters, so the description doesn't need to explain any. The baseline for 0 params is 4, and the description adds meaning by clarifying that the list is scoped to the user's account and includes published apps, which aligns with the parameter-free design.

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 it lists published apps attached to the user's account, using the specific verb 'Liste' and scope 'apps publiées rattachées au compte de l'utilisateur'. This distinguishes it from sibling tools like get_app (singular) and update_app, which target a single app.

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 explicitly provides trigger scenarios: when the user asks 'quelles sont mes apps', wants to find the address of a previously published app, or wants to modify an app without having its token. This gives clear context on when to use the tool, though it doesn't explicitly exclude other tools or name alternatives, warranting a 4.

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 full burden, and it does well by disclosing that no account is needed, the published app is publicly accessible, it can be locked to the user's account, and localStorage alone won't survive device changes. It lacks some details like response format or failure behavior, but the core operational traits are clearly exposed.

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 first sentence delivers the core action and result, followed by clearly separated usage, persistence, and confidentiality guidance. Each labeled section earns its place with actionable information, and there is no redundant or filler content.

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 publish tool with no output schema and no annotations, the description is highly complete: it covers when to use the tool, the no-account requirement, the public visibility and locking option, and the critical data-persistence caveat. Together with the fully documented input schema, this gives the agent everything needed 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 description coverage is 100%, so the baseline is 3 even without additional parameter details. The description adds useful context about data persistence and personal-data handling, but it does not meaningfully enhance per-parameter semantics beyond what the schema already documents.

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 states precisely that the tool publishes a single-file HTML app and returns its public URL. It also distinguishes itself from siblings by framing this as the action for hosting/publishing/sharing a newly created app, rather than claiming, updating, deleting, or managing 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?

It explicitly says to call the tool when the user wants to host, publish, put online, or share an HTML app, and it points to get_publishing_guide for additional guidance. It also gives a strong directive about wiring persistence before publishing, but it does not explicitly say when not to use it, such as for updating an existing app.

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 full burden. It clearly warns that previous data is permanently lost and advises warning the user. This is critical behavioral disclosure for a destructive operation. It doesn't mention authentication or rate limits, but the core destructive nature is well-covered.

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 three sentences long, with the main action front-loaded. Each sentence adds value: what it does, when to use it, and what to warn about. No filler or 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?

Given the tool's destructive nature and lack of output schema, the description covers the essential context: purpose, usage, and irreversible consequences. It doesn't mention return values or error conditions, but these may be less critical. Overall, it provides solid contextual guidance for an agent.

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 67% (data and secret_token are described, slug is not). The description adds context about the data parameter being the entire JSON document and the destructive consequence, but does not provide additional meaning for slug or secret_token beyond the schema. It is adequate but not exemplary.

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 that the tool overwrites the app's JSON document, with a specific verb ('Écrase') and resource. It distinguishes itself from siblings by noting it's the only way to replace existing data, which differentiates it from tools like update_app or get_app_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?

The description provides explicit use cases: migrating data to a new structure or starting from scratch. It implies this is for full replacements, not partial updates, though it doesn't explicitly name alternatives. The 'seule façon' phrasing helps clarify when to use 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that user data is never overwritten ('Les données déjà enregistrées par les utilisateurs ne sont jamais écrasées'), that the URL does not change, and provides a migration workflow. This is exceptional transparency for a mutation tool, covering both what it does and what it avoids doing.

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 three sentences long, front-loaded with the primary purpose in the first sentence. The second sentence adds a key constraint (URL unchanged), and the third adds a crucial behavior (data preservation) with a concrete workflow. Every sentence earns its place; no wasted words.

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

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

The description covers the tool's purpose, key constraints, and a specific workflow for data migration. Given the absence of an output schema or annotations, it is quite complete, but it does not mention the response/return value or error conditions. Still, the core behavior and its limits are well explained.

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 80% (4 of 5 params have descriptions), so the schema already handles most parameter meaning. The description adds high-level context (replaces HTML/title, doesn't touch data) that aligns with the 'html' and 'data' params, but does not go into parameter-specific syntax or format. It meets the baseline for high schema coverage without adding significant detail 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 the tool's core function: 'Remplace le HTML et/ou le titre d'une app déjà publiée.' It specifies the resource (published app) and the exact actions (replacing HTML and/or title), and immediately distinguishes itself from siblings like publish_app (create) and set_app_data (update data). The added 'L'URL ne change pas' also clarifies the scope.

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 for when to use this tool (updating an already-published app's HTML/title) and explicitly points to alternatives in a key scenario: 'si votre nouvelle version change la structure des données, lisez d'abord get_app_data puis migrez avec set_app_data.' It does not, however, offer a general use-case comparison with all sibling tools, but the purpose already implies the right usage.

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