Skip to main content
Glama
Sign In
wasmagent-mcp-server

wasmagent-mcp-server

by WasmAgent
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

docs_search

Search for available downstream tools by name or substring. Use this before calling execute_code to discover which tools can be used.

Instructions

Look up the available downstream tools by name or substring. Call this BEFORE writing an execute_code script to learn what's available.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "docs_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
namesNoOptional list of exact tool names to fetch. Takes precedence over `query`.
queryNoSubstring to filter tool names/descriptions. Empty/omitted returns all.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.1/5.0
Behavior3/5

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

No annotations provided, so description must carry burden. It describes the search function but does not disclose any behavioral traits like idempotency, rate limits, or auth requirements. Lacks detail on what exactly is returned.

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?

Two concise sentences, front-loaded with purpose, no wasted words.

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

Completeness3/5

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

Lacks output schema and does not describe return format. Since tool is used before writing code, knowing output structure is important. Incomplete in that aspect.

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

Parameters4/5

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

Schema coverage is 100%, but description adds value by noting that empty query returns all and that names takes precedence over query. Enhances understanding beyond 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?

Description clearly states it looks up downstream tools by name or substring, distinguishing it from the sibling tool execute_code which executes code.

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?

Explicitly states to call BEFORE writing an execute_code script, providing clear context. Does not mention when not to use or alternatives, but sibling list is limited.

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

Deploy Server

Other Tools