ToolSpec
@forge/monorepo / backend/src / ToolSpec
Type Alias: ToolSpec<I, O>
ToolSpec<
I,O> =object
Defined in: backend/src/tools/define.ts:16
Type Parameters
I
I = unknown
O
O = unknown
Properties
approvalPolicy?
readonlyoptionalapprovalPolicy?:ApprovalPolicy
Defined in: backend/src/tools/define.ts:22
category?
readonlyoptionalcategory?:string
Defined in: backend/src/tools/define.ts:20
description
readonlydescription:string
Defined in: backend/src/tools/define.ts:18
effect?
readonlyoptionaleffect?:ToolEffect
Defined in: backend/src/tools/define.ts:21
inputSchema?
readonlyoptionalinputSchema?:unknown
Defined in: backend/src/tools/define.ts:23
label?
readonlyoptionallabel?:string
Defined in: backend/src/tools/define.ts:19
name
readonlyname:string
Defined in: backend/src/tools/define.ts:17
outputSchema?
readonlyoptionaloutputSchema?:unknown
Defined in: backend/src/tools/define.ts:24
requiredScopes?
readonlyoptionalrequiredScopes?: readonlystring[]
Defined in: backend/src/tools/define.ts:39
The provider scopes this tool needs — #260's field, made settable by #234.
It was declared on ToolDescriptor and had no way to be set: ToolSpec did not carry it, so nothing
in the repository could populate it and nothing read it. A field that cannot be written is a field that
documents an intention rather than expressing one, which is the defect class check:reachability exists
for — it was missed because the check asks whether declared fields are read, and an unwritable field is
never read either.
Google is the first vendor where it matters: gmail.send and gmail.readonly are different consents, and
asking for the wrong one is the difference between a security team approving an integration and refusing
it.
requiresIdempotencyKey?
readonlyoptionalrequiresIdempotencyKey?:boolean
Defined in: backend/src/tools/define.ts:25
Methods
execute()
execute(
input,context):O|Promise<O>
Defined in: backend/src/tools/define.ts:40
Parameters
input
I
context
Returns
O | Promise<O>