expo_add_config

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

Annotations are entirely absent, so the description carries the full burden for safety and side-effect disclosure, but it does not say whether this modifies existing config files, overwrites app.json/app.config.js, requires network access to npm plugins, or is destructive to existing settings. Without annotations, this is a notable gap for a mutation tool.

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 short—five words—which is concise, and the name aligns with the description, but it is so terse that it offers minimal information. One sentence is appropriate for this tool's scope, but it could clarify the purpose of the api_key parameter without losing conciseness.

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 no annotations, no output schema, and only one of two parameters described in the schema, the overall context is insufficient for an agent to invoke the tool correctly. The description doesn't mention expected config file location, supported plugin names, or what specifying directory does. It is a thin description for a tool that presumably writes to a project's Expo configuration.

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 only 50%: directory is described as 'Project directory' and api_key has no schema description. The tool description doesn't explain what api_key is for or how it is used with the plugins. The schema already reveals 'directory' is required; the description adds no semantics for the optional api_key, so the agent cannot reason about when to provide it.

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 name 'expo_add_config' and description 'Add Expo configuration plugins' identify a general modify operation for Expo configuration. The verb and resource are present, but it doesn't specify what configuration plugins are added, which plugins are supported, or what the actual config output is. Given many sibling expo tools (expo_generate_project, expo_setup_eas), it is distinguishable as an add-action, but not as a specific implementation of that 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?

The description gives no indication of when to use this tool versus expo_setup_eas or expo_generate_project, no prerequisites (e.g., a scaffolded project required), and no note about what happens if the directory is invalid. It is minimally usable only if the agent already knows to call it for Expo plugins.

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