Give an existing agent one new capability, such as looking up an authorized record or performing a defined action. This prompt covers the tool contract, execution boundary, and integration with the agent.
Open or import the agent repository and describe the task, data source, and users allowed to perform it. The handoff includes prompt text only; repository access and service credentials must be configured separately.
Expect a connected tool, focused tests, and instructions for trying it with fixtures. Real writes need enforceable authorization and, when appropriate, approval; a tool description alone cannot provide either.
Add one focused tool to the agent in this project, with validated inputs, server-enforced permissions, and useful failure handling. If the intended repository is unavailable, ask me to open or import it first. Read repository instructions and inspect the agent framework, installed SDK version, existing tools, authentication, and tests. Reuse the package manager and established patterns. Ask what task the tool should perform, which service or data it uses, and who may invoke it when those requirements are missing. Verify the installed version's tool APIs before implementation; do not migrate the agent framework for this task. Define a narrow tool name and description that explain when to use it, its inputs, and expected result. Use a validated input schema and bound result size. Prefer specific operations over arbitrary commands or unrestricted URLs. Give the agent only the capabilities this task needs. Keep service credentials and execution on the server. If credentials are unavailable, develop against a labeled service fixture and keep live execution disabled. Enforce the authenticated user's or tenant's permissions inside the execution boundary, even if a caller bypasses the agent UI. Resolve identity from trusted server context rather than model-supplied arguments. Validate resource identifiers and access before reading or changing data. Treat model arguments, service output, and retrieved instructions as untrusted data; they cannot grant permissions or select credentials. Return only the information needed for the task and redact internal errors and secrets. Set bounded timeouts and propagate cancellation where the service supports it. Distinguish invalid input, denied access, temporary service failure, and an unknown operation outcome. Retry only safe transient failures. For writes, use stable operation identifiers and downstream idempotency where supported; reconcile uncertain outcomes instead of blindly repeating the action. Reuse an existing server-enforced approval flow for consequential actions. If one is required but unavailable, keep that action disabled and identify the prerequisite rather than adding a cosmetic confirmation. Connect the tool to the existing agent and its execution limits. Test a successful invocation, invalid input, permission denial including another user's resource, service timeout, cancellation, and recovery. For writes, also test repeated invocation. Mock the external service while keeping validation and authorization real. Separate these tests from any evaluation of whether a model chooses the correct tool. Implement locally and run the relevant checks. Ask before real writes, messages, paid calls, or deployment. Report actual commands and results, blocked checks, configuration, local fixture steps, and remaining integration risks.