Safari MCP Server

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 adds valuable technical scope ('Works with both fetch and XHR') not evident in the schema. However, it omits critical behavioral details: mock persistence duration (session vs. permanent), scope (current page vs. all tabs), and whether this is destructive to existing network interception. Given the existence of safari_clear_mocks, mentioning persistence would be valuable.

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?

Three sentences with zero waste: sentence one establishes core functionality, sentence two adds technical scope (fetch/XHR), and sentence three provides usage context. Every sentence earns its place, and the description is front-loaded with the essential 'intercept and return mock' concept.

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 tool with 2 parameters, 100% schema coverage, and no output schema, the description is appropriately complete. It covers mechanism, technical constraints, and use cases. The only gap is the lack of mention regarding mock lifecycle management (relationship to safari_clear_mocks) or precedence rules for overlapping patterns, which would be relevant given the tool's behavioral impact.

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%, establishing a baseline of 3. The description references 'URL pattern' and 'mock response,' which map to the parameters, but adds no semantic detail beyond the schema's already-comprehensive descriptions (e.g., it doesn't clarify regex syntax specifics or provide response body examples). The schema does the heavy lifting here.

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 'Intercept network requests matching a URL pattern and return a mock response,' providing a specific verb (intercept), resource (network requests), and action (return mock). The mention of 'fetch and XHR' distinguishes it from general network monitoring tools, and the 'mock' terminology clearly differentiates it from siblings like safari_network or safari_throttle_network.

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 usage scenarios: 'Useful for testing API error states, offline behavior, or replacing API responses.' This gives clear 'when-to-use' context. However, it lacks explicit 'when-not-to-use' guidance or mention of the complementary safari_clear_mocks tool for cleanup, which would be helpful given the persistent nature of mocks.

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