Skip to main content
Glama

propose_template_update

Read-onlyIdempotent

Propose a DRAFT strategy template from an emerging pattern.

PROPOSE-AND-APPROVE ONLY. Creates a draft template that is NOT published, NOT verified and NOT eligible for cloning; an administrator must explicitly approve it before it can appear in the marketplace. This tool can never publish, verify, or modify an existing live template, and never auto-applies anything. pattern_id comes from get_emerging_patterns; only an active, released pattern may be proposed. Descriptive historical observation -- not a recommendation, not financial advice, and not a promise of future results.

Workflow: PROPOSE step -- raise an observed emergent motif for human review; approval and any publication remain a human decision.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
caller_idNo
pattern_idYes
descriptionNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

B3.4/5.0
Behavior1/5

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

Annotation Contradiction: description says 'Creates a draft template' while annotations declare readOnlyHint=true, a direct conflict similar to a documented write operation marked read-only. Although the description adds useful lifecycle detail (not published, needs admin approval), the contradiction forces a 1.

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?

Well-structured with a clear lead, bold workflow label, and front-loaded constraints; however, the lifecycle and workflow points are restated several times ('PROPOSE-AND-APPROVE ONLY', 'Workflow: PROPOSE step', 'approval ... remain a human decision'), adding mild redundancy.

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?

For a single-required-parameter tool with an output schema and rich annotations, the description covers lifecycle, constraints, and source. The main gap is the unexplained optional parameters, though these are non-essential for a basic correct call.

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

Parameters2/5

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

Schema description coverage is 0%, so the description carries the burden. It explains pattern_id's source and eligibility constraint but says nothing about name, caller_id, or description; caller_id in particular has no inferable meaning from the description.

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?

Description opens with a specific verb and resource: 'Propose a DRAFT strategy template from an emerging pattern.' It distinguishes itself from publishing, verifying, or cloning by stating it creates only a non-published draft, and from siblings like approve_proposal/publish_strategy via 'PROPOSE-AND-APPROVE ONLY.'

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

Usage Guidelines4/5

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

Provides explicit preconditions: pattern_id must come from get_emerging_patterns and be an active, released pattern. It states what the tool cannot do (publish, verify, modify live templates, auto-apply), but does not explicitly name the approval/publishing siblings as next steps.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.2/5.0
Disambiguation2/5

Multiple tools overlap significantly: close_perp_position vs perp_close, get_leaderboard vs get_score_leaderboard vs get_strategy_leaderboard, get_venue_status vs get_all_venues_status, send_token_social vs bulk_send_social, and get_crank_score vs get_score. Several read-only tools have nearly identical purposes, and the descriptions do not always clarify boundaries.

Naming Consistency4/5

Most tools follow a consistent verb_noun snake_case pattern (get_balances, create_strategy, set_alert, list_webhooks). However, there are deviations like 'lst_swap', 'jupiter_swap', 'flash_loan', 'sr_backtest', and the use of both 'get_' and 'list_' for reads, plus category prefixes like 'perp_' and 'strategy_' that vary in order. Overall still readable and predictable.

Tool Count1/5

177 tools is an extreme count for any server, far exceeding the 25+ threshold for 'too many'. Even a full DeFi platform does not need this many separate operations; the surface is overwhelming and clearly not well-scoped.

Completeness3/5

The domain (Solana DeFi trading) is covered extensively across swaps, perps, lending, staking, strategies, signals, and support. However, there are notable gaps: no lend_withdraw, no direct way to close a lending position, no spot order cancellation (though aggregator-based swaps may not need it), and a general lack of tiered account management. The huge number of tools makes it hard to identify missing lifecycle steps.

Resources