Skip to main content
Glama

AgentPlaybooks

by ai.agentplaybooks

Write through a secret

use_secret_write
Destructive

Send a POST, PUT, PATCH or DELETE request with a secret injected as a header, and return the response. The secret value is never returned to the agent — it is decrypted and used server-side only. This changes state in the remote API and cannot be undone from here. The URL is chosen by the caller, so the target is whichever API the secret belongs to — see that API's own documentation for paths and payloads. Requires secrets:read or full permission. Use use_secret for GET and HEAD, list_secrets to discover names, and store_secret or rotate_secret to change a stored value rather than send a request. Pass playbook_id as the UUID or GUID of the playbook this call should target.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe URL to send the HTTP request to
bodyNoJSON request body (for POST/PUT/PATCH)
methodNoHTTP method (default: POST). For GET/HEAD use use_secret.
timeout_msNoRequest timeout in milliseconds (default: 30000, max: 60000)
header_nameNoHeader name to inject the secret into (default: Authorization)
playbook_idYesUUID or GUID of the target playbook
secret_nameYesName of the secret to use (e.g. DEPLOY_API_KEY)
extra_headersNoAdditional headers (e.g. {"Content-Type": "application/json"})
header_prefixNoPrefix before the secret value (default: 'Bearer '). Use empty string for raw value.

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that the secret is never returned to the agent, is decrypted server-side, changes state, and cannot be undone. While annotations already indicate destructiveHint=true and readOnlyHint=false, the description adds crucial security context (secret not leaked) and irreversibility.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear first sentence, followed by behavioral warnings and usage alternatives. It is slightly long but every sentence adds value, and it front-loads the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 9 parameters, 100% schema coverage, and no output schema, the description sufficiently covers the tool's behavior and safety. It doesn't explain return format but that's not required without an output schema. The complexity is high, but the description handles it well.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds a few nuances (header injection, prefix defaults, method default) but mostly repeats schema info. It doesn't explain the semantics of extra_headers or body beyond what's in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool sends POST, PUT, PATCH, or DELETE requests with a secret injected as a header, distinguishing it from use_secret (GET/HEAD). It also clarifies the purpose is to perform state-changing operations on remote APIs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use (state changes) and when-not-to-use (use use_secret for GET/HEAD, list_secrets for discovery, store_secret/rotate_secret for changes). Also notes the caller chooses the URL and should refer to the target API's documentation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All AgentPlaybooks toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool targets a distinct entity and action (e.g., delete_memory vs delete_skill vs delete_run), and even similar operations like read_memory vs search_memory vs get_memory_context have clearly differentiated purposes. The descriptions are detailed and explicitly cross-reference other tools to avoid confusion.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (create_*, list_*, update_*, delete_*, read_*, etc.), with plurals used uniformly for list operations (list_playbooks, list_runs, list_secrets). No mixed conventions or ambiguous verbs; the naming is highly predictable and systematic.

Tool Count4/5

With 48 tools, the server covers a broad but coherent set of domains (playbooks, personas, skills, memory, canvas, runs, secrets, MCP servers, and discovery). While this exceeds the typical 3-15 range, each tool serves a distinct and necessary function within the comprehensive playbook management scope, so the count feels justified rather than bloated.

Completeness5/5

The tool surface provides complete CRUD and lifecycle coverage for every entity type: playbooks, personas, skills (including versioning and rollback), memory (including hierarchical tasks and tiering), canvas (with locking and patching), runs, secrets (including rotation and usage), and MCP servers. Additionally, find_tools covers discovery for federated tools, leaving no apparent dead ends.

Resources