Files
python-sdk/examples/tools/__main__.py
T
zeekayandHanzo Dev 3a09eb4319 regenerate from cloud@5126939 — the client leaves the hand-merged lineage
pkg/hanzoai/cloud goes +2186 -2126 ~175: 1700 paths / 2354 operations / 2186
schemas, 182 api modules and 2172 model modules, against the 239/1116 it carried
from hanzo.yaml. The document is hanzoai/cloud's own emission now, pinned in a
new .spec-lock by commit and sha256, and generate.py reaches it by value —
--skip-validate-spec means the 1012 missing-`responses` errors no longer write
zero files, so a client can be cut from the authority instead of a projection of
it.

Two renamings come with that, and both are the fix rather than the damage. IAM's
types are namespace-qualified (iam.Role, iam.Application, 95 of them) because a
bare `Role` was two unrelated shapes wearing one name. And the <svc>_ prefix is
gone from every operationId, so every generated method lost it.

The prefix is what broke the examples, and the gate saw only two thirds of it.
Four flows failed on their imports; `money` and `tools` PASSED while every call
in them named a method that no longer existed — an import resolves the names in
the `from … import` line and a method is looked up at call time. All five flows
now name operations that exist, checked by resolving each one as an attribute,
and hanzo.yml records that ceiling so the next reader does not trust the gate
for more than it says.

`chat` is removed, which is a measurement and not a preference: cloud declares
POST /v1/chat/completions with no requestBody and no responses at all, so the
generated method takes no body and returns None — the one call a chat example
exists to make cannot be expressed. Inventing the type, or hand-rolling the HTTP
inside a generated client, is the drift these SDKs exist to prevent; js-sdk
dropped its own chat flow at 2.0.7 for exactly this. It returns the release
cloud gives that route a body.

Two smoke assertions were already red before this regeneration and are now true
again: they pinned AIApi/APIKeysApi/MCPApi and AdminApi.plugin_admin_*, names
from the retired lineage. The surface is all still there under AiApi/KeysApi/
McpApi and AdminApi.admin_plugins.

tests/test_zap_transport.py still errors, exactly as it did before: it imports
`Hanzo` from hanzoai, which the hand-written package does not define. That is
not this document's business and is untouched.

Minor rather than patch: every generated method changed name.

Co-authored-by: Hanzo Dev <[email protected]>
2026-08-05 11:00:03 -07:00

37 lines
1.3 KiB
Python

"""tools — list the tools this key can reach.
``GET /v1/tools`` (operationId ``get_v1_tools``), the catalog behind the
MCP surface: each entry is a tool name, its description and its input schema.
A note on the MCP door, because it is easy to pick the wrong one. There is a
live JSON-RPC endpoint at ``POST /v1/mcp`` that answers ``tools/list`` with the
same catalog (730 tools at the time of writing) — but it is NOT in hanzo.yaml,
so the generator emits no method for it and an example would have to bypass the
SDK to call it, which defeats the point of an SDK example. Of the MCP routes
that ARE declared, ``/v1/automations/mcp`` returns 405 at api.hanzo.ai. So this
catalog read is the one that is both generated and served. When ``/v1/mcp`` is
added to the spec, this flow should move to it.
python -m examples.tools
"""
from hanzoai.cloud import ToolsApi
from examples.client import client, run
def main() -> None:
with client() as api:
catalog = ToolsApi(api).get_v1_tools()
tools = catalog.tools or []
print(f"{len(tools)} tools")
for tool in tools[:20]:
print(f" {tool.name} — {tool.description or '(no description)'}")
if len(tools) > 20:
print(f" … and {len(tools) - 20} more")
if __name__ == "__main__":
run(main)