Add inverse and bulk assertions for tool list inspection

[othercodes]

Context

When using AssertableMCP.lists_tools() to inspect a tools/list response, the current public API supports:

• contains_tool(name) / contains_tool(name, callback) — assert a tool exists, optionally with per-tool assertions via callback
• does_not_contain_tool(name) — assert a tool is absent
• with_count(n) — assert the list size
• Inside the callback (AssertableToolDef): accepts(params), accepts_optional(params), documented(), has_output_schema()

Two gaps come up in practice:

1. No way to assert that a tool does NOT advertise an optional property. accepts_optional([\"x\"]) asserts the property is present, but there is no inverse — useful when a server transforms its tool schema based on auth context (e.g., stripping internal-only parameters for restricted clients).

2. No way to apply the same assertion to every tool in the list. contains_tool is per-name, so verifying a uniform invariant ("no tool exposes property X") requires enumerating every tool name in the test, which couples the test to the full catalog.

Proposed API

AssertableToolDef.does_not_accept_optional(params)

response.assert_mcp().lists_tools().contains_tool(
    "search",
    lambda t: t.does_not_accept_optional([\"internal_user_id\"]),
)

Raises AssertionError if any of the listed params are present in inputSchema.properties.

AssertableToolList.every_tool(callback)

response.assert_mcp().lists_tools().every_tool(
    lambda t: t.does_not_accept_optional([\"internal_user_id\"])
)

Applies the callback to every AssertableToolDef in the list. Useful for asserting catalog-wide invariants (uniform schema transformations, no leaked internals, etc.) without naming each tool.

Suggested implementation

class AssertableToolDef:
    def does_not_accept_optional(self, params: list[str]) -> Self:
        properties = list((self._definition.get(\"inputSchema\") or {}).get(\"properties\") or {})
        present = [p for p in params if p in properties]
        if present:
            raise AssertionError(
                f\"Tool '{self._name}' should not expose properties {present!r}; \"
                f\"properties={properties!r}\"
            )
        return self


class AssertableToolList:
    def every_tool(self, callback: Callable[[AssertableToolDef], Any]) -> Self:
        for tool in self._tools:
            callback(AssertableToolDef(tool))
        return self

Use case

Servers that conditionally rewrite their tool catalog per-caller (auth scopes, feature flags, public-vs-admin views) need to assert both the positive ("admin sees X") and negative ("public does not see X") sides of the transformation. The current API supports the positive side cleanly; the negative side requires either enumerating every tool by name or dropping to private attributes like _definition.

[othercodes]

Implemented in #31 with a small scope change worth flagging.

What shipped

• ✅ AssertableToolList.every_tool(callback) — as proposed.
• 🔄 AssertableToolDef.does_not_accept(params) instead of the proposed does_not_accept_optional(params).

Why a single inverse instead of two

The existing positive forms have an asymmetry that's easy to miss:

• accepts(["x"]) → checks inputSchema.required
• accepts_optional(["x"]) → checks inputSchema.properties (i.e. "is exposed", regardless of required vs optional)

So accepts_optional is misleadingly named — it doesn't validate "is optional", it validates "is exposed in the schema at all". Propagating that confusion to the inverse (does_not_accept_optional) would mean: "x is not exposed at all" — which is exactly the use case from the issue (auth-stripped properties), but the name obscures the semantics.

does_not_accept(params) is unambiguous: the tool does not accept this param (not in inputSchema.properties). Covers both required and optional in one method. No companion does_not_accept_required is provided because that asks a weak question with no documented use case.

Implementation note

every_tool skips non-dict entries silently to stay consistent with the existing contains_tool / does_not_contain_tool behaviour. If the project later decides to harden malformed-response handling, all three should be aligned in a separate PR.