tools.write_python_tool module
Create new Python tool files in the tools/ directory.
This tool writes a new .py file into the tools/ directory and handles all downstream registration automatically:
Syntax validation – parses the code with AST before writing.
File creation – writes the .py file (optionally overwriting).
Markdown docs – generates a Markdown doc from the source and indexes it into the
stargazer_docsRAG store so it is immediately searchable. Also creates an RST stub for the next full Sphinx rebuild.Registry reload – hot-reloads the tool registry so the new tool is callable in the same conversation.
Classifier embeddings – regenerates vector embeddings so the tool can be auto-selected by future prompts.
Requires the UNSANDBOXED_EXEC privilege.
What the LLM actually sees at tool-selection time
The OpenAI function-calling API sends exactly three fields per tool:
TOOL_NAME→function.nameTOOL_DESCRIPTION→function.description← the ONLY prose the LLM reads when deciding whether to call a toolTOOL_PARAMETERS→function.parameters
Module docstrings and run() docstrings are NOT sent to the LLM
directly. They are auto-extracted into Markdown docs and indexed into
the stargazer_docs RAG store, where the LLM can search them later
with rag_search.
Documentation best practices
TOOL_DESCRIPTION must be self-contained and comprehensive. It is the ONLY text the LLM sees at tool-selection time. Write it so that any future instance of Stargazer can understand the tool’s purpose, constraints, and usage in any context.
Function docstrings feed the auto-generated Markdown docs in the
stargazer_docsRAG store. Document every public function, parameter, and edge case for deeper reference.
- async tools.write_python_tool.run(tool_code, tool_name, description=None, overwrite=False, ctx=None)[source]
Write a new Python tool file and run the full registration pipeline.
Entry point for the
write_python_tooltool. It is admin-gated: it first requires the caller to holdUNSANDBOXED_EXEC, then validates and optionally docstring-wraps the source, writes the.pyfile undertools/, and performs the downstream wiring that makes the tool usable in the same conversation — manifest allow-listing, hot registry reload, Sphinx/RAG doc generation, and classifier-embedding refresh so the tool can be auto-selected later. Failures at any stage degrade gracefully and roll back the file when the manifest update fails.Interactions and side effects: gates via
tools.alter_privileges.has_privilege(); validates with_validate_python_code(); computes the path with_generate_filename()and writes the file withaiofiles; appends to the tool manifest viatool_loader.append_tool_manifest(unlinking the file on failure); generates docs and RAG-indexes them via_generate_docs_stub()(run in a thread); hot-reloads the registry by clearing and re-runningtool_loader.load_toolsunder the registry lock; and regenerates vector embeddings viaclassifiers.refresh_tool_embeddings.refresh_tool_embeddings. It readsuser_id,redis,config, andtool_registryoffctx. Dispatched by the tool loader, which resolves the module’srunattribute (tool_loader.py); no direct internal callers were found.- Parameters:
tool_code (
str) – Complete Python source for the new tool file; must be non-empty and pass syntax validation.tool_name (
str) – Canonical tool name; used to derive the filename and doc paths.description (
str) – Optional human-readable description; whentool_codelacks a module docstring, one is auto-prepended from this value.overwrite (
bool) – WhenTrue, replace an existing file; otherwise an existing file is an error.ctx (
ToolContext|None) – Tool context providinguser_id,redis,config, andtool_registryfor the privilege check, write, and registration steps.
- Returns:
A JSON string. On success it reports
success,filename,filepath,functions_registered, and thereload_success/embedding_success/docs_generatedflags; on failure it reportssuccess: falsewith anerror(andvalidation_errors/warningswhen validation failed).- Return type: