Create profile

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

Beyond annotations, the description discloses key behavioral traits: 'nothing changes until you activate it', 'An existing profile of the same name is left untouched rather than overwritten', storage path under ~/.nodriver-mcp/profiles/<name>, and the one-instance-per-profile constraint. These add meaningful context without contradicting 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?

The description is four sentences, front-loaded with a crisp definition, followed by high-value context (persistence, alternatives, side effects, path, concurrency). Every sentence contributes new information, with no fluff or repetition of schema 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?

Given the tool's moderate complexity, annotated metadata, and fully described schema, the description covers all necessary aspects: purpose, alternative tools, side effects, safety, storage location, and usage constraints. No major gaps remain.

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% and both parameters have detailed descriptions already. The description adds extra context beyond the schema by explaining that profiles live at a specific filesystem path and that activation can happen later via use_profile, which enriches understanding of the `activate` parameter. However, the schema already covers the immediate meaning of both parameters, so not a 5.

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 and resource: 'Create a named persistent Chrome profile — a reusable user-data dir.' It clearly distinguishes this from siblings by calling it 'the sturdier alternative to save_session / load_session' and by explaining persistent profiles keep cookies/logins between runs. This makes the tool's purpose 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?

Explicitly positions the tool against alternatives: 'It is the sturdier alternative to save_session / load_session.' It also explains that creation alone is harmless and that activation can happen later via use_profile, giving clear context for when to use this tool versus siblings. The concurrency warning ('Only one browser instance can use a given profile at a time') provides a practical when-not/limitation.

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