agent4.io

test_skill_trigger

Reality-check whether your prompts actually trigger tool calls (dry-run) — run this after writing/changing a skill instead of counting corpses in production.

Replays your messages N times against the **production** system-prompt assembly, tool schemas
and this tenant's actual model routing, capturing only the model's tool-call decision: **tool
side effects are NOT executed**, no session is stored. Tokens count toward the tenant quota
(messages≤5, samples≤5, at most 25 calls per invocation — pick test messages carefully).

Two modes for the skill's two battlefields:
- loaded=false (default): first turn, skill not loaded — tests whether the trigger in
  description works;
- loaded=true: simulates post-load_skill — tests the quality of instructions (incl. few-shot
  examples).

Returns per-message hit counts plus claimed_without_call (the model said "noted" WITHOUT
calling the tool — the worst failure, fix first). Cover edge cases in your test messages:
numbers with spaces, buried in long questions, corrections, email-only. The loop:
create_skill → check warnings (static lint) → test_skill_trigger (dynamic reality check) →
adjust description / add examples → re-test until the hit rate holds.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`agent`	Yes
`skill`	No
`loaded`	No
`samples`	No
`messages`	Yes
`expect_tool`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It clearly states that 'tool side effects are NOT executed', 'no session is stored', tokens count toward quota, and there are hard limits (messages≤5, samples≤5, at most 25 calls). It also explains what is captured (tool-call decision) and highlights the 'claimed_without_call' failure mode. This is exceptionally transparent.

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

Conciseness5/5

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

Though long, the description is well-structured and front-loaded with the core purpose. Each sentence adds value: purpose/safety, modes, limits, return fields, and a concrete workflow. No filler or redundancy is present, and the bullet-like format aids scanability. Given the tool's complexity, this level of detail is justified and earns a high score.

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

Completeness5/5

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

The tool is complex with 6 parameters, two modes, side-effect safety, and return analytics. The description covers all key aspects: what it does, when to use it, how parameters map to behaviors, limits, expected outputs (hit counts, claimed_without_call), and even edge-case testing advice. An output schema exists, so omitting detailed return structure is acceptable. This is a complete, self-contained description.

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 description coverage is 0%, so the description must compensate. It explains 'loaded' in detail, gives limits for 'messages' and 'samples', and implies 'skill' and 'agent' through workflow context. However, the 'expect_tool' parameter is never mentioned or explained, and 'agent' is only indirectly referenced via 'tenant's actual model routing.' Given 6 parameters, this is partial but not complete coverage, so the minimum viable score of 3 is appropriate.

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 opens with 'Reality-check whether your prompts actually trigger tool calls (dry-run)', using a specific verb and resource that clearly distinguishes this from siblings like diagnose_prompt or improve_prompt. It explicitly frames the tool as a dry-run test rather than a production action, making its purpose unmistakable.

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?

The description gives explicit when-to-use guidance: 'run this after writing/changing a skill' and contrasts with 'instead of counting corpses in production.' It details two modes (loaded=false vs loaded=true) with specific use cases, and even outlines a full workflow loop (create_skill → check warnings → test_skill_trigger → adjust → retest). This is exemplary usage guidance.

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

All agent4.io tools Inspect

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

A3.6/5.0

Disambiguation4/5

Tools are mostly distinct by domain and action. A few pairs like add_knowledge_file vs add_knowledge_text or build_knowledge_index vs patch_knowledge_index could cause confusion, but descriptions clearly differentiate them.

Naming Consistency4/5

The vast majority follow a consistent verb_noun snake_case pattern (create_*, list_*, get_*, update_*). A few outliers like tenant_info, usage_stats, and page_context_stats are noun-first, deviating slightly from the otherwise uniform scheme.

Tool Count1/5

With 50 tools, this is a very large surface that exceeds typical well-scoped server sizes. Even for a broad platform management API, the sheer number makes it heavy and potentially overwhelming, matching the '50+' extreme mismatch category.

Completeness2/5

The server covers creation, reading, updating, and listing for most resources but lacks any delete operations (no delete_agent, delete_knowledge_base, delete_skill, delete_share, delete_storyline, delete_page_context). This is a significant gap in lifecycle coverage that will force agents to work around missing functionality.

Resources

Need Help?