Skip to main content
Glama
Sign In
esa MCP Server

esa MCP Server

Official
by esaio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Search esa documentation and help

esa_search_help
Read-only

Search esa documentation for features, terminology, and specifications when you need help with esa-specific terms or workflows you are not familiar with.

Instructions

Search esa documentation for features, terminology, and specifications. Use this when users mention esa-specific terms, ask about esa functionality, or request help with esa workflows that you're not familiar with.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "esa_search_help"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoPage number
queryYesSearch query string. Use specific terms, not wildcards like "*". Empty string returns all posts. ## Important Note for Date Queries: **WARNING: Do NOT use 'after:', 'before:', 'since:', or 'until:' syntax (these are from GitHub/Gmail/pplog). Use esa-specific date syntax: created:>YYYY-MM-DD, created:<YYYY-MM-DD, updated:>YYYY-MM-DD, updated:<YYYY-MM-DD ## Important Note for Relative Date Queries: **CRITICAL: Always get today's actual date from the system before processing relative date queries (e.g., "today", "yesterday", "last week", "recent"). When searching, apply these strategies: 1. Convert concepts to technical terms (e.g., general descriptions → specific property names, method names, or technical keywords) 2. Translate between Japanese and English technical terms (e.g., Japanese concepts → English API/property names) 3. Expand to related technical elements (e.g., one concept → multiple implementation approaches, related technologies, or alternative solutions) IMPORTANT: Space-separated terms are treated as AND conditions. Use "OR" operator for alternative terms: "word-break OR word-wrap OR overflow-wrap". Advanced search: "tag:release", "category:dev", "wip:false", "keyword:API", "title:設計書". Category search: "on:category" (posts directly in category), "in:category" (posts in category and subcategories), "on:/" (uncategorized posts). For broader results, use OR between related terms rather than listing them with spaces.
perPageNoItems per page

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.15.1
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / page / maximum
      Added value: +9007199254740991
  2. First observedv0.13.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds no behavioral detail beyond that: no indication of what a result looks like, whether it searches help-team posts versus static docs, or how paging behaves — notable given the schema is a full post-search query syntax.

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?

Three short lines, front-loaded with the purpose followed by usage context. No filler, though the first sentence largely restates the title.

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?

For a 3-parameter, read-only tool with annotations, the essentials are covered, but with no output schema the agent has no idea what the tool returns, and the description never clarifies that the query syntax is a post-search syntax rather than a plain documentation keyword search — a real risk of malformed calls.

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 100% and the query parameter carries extensive guidance (date syntax, OR operators, tag:/category: operators), so the schema does the heavy lifting. The description contributes nothing about the query or page/perPage semantics; baseline 3 applies.

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

Purpose4/5

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

States a specific verb and resource: 'Search esa documentation for features, terminology, and specifications.' An agent can tell this apart from post-oriented siblings like esa_search_posts, but nothing distinguishes it from the other help-oriented siblings (esa_get_search_options_help, esa_get_markdown_syntax_help), so which help tool to open remains ambiguous.

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?

Gives concrete triggers: users mention esa-specific terms, ask about esa functionality, or request help with workflows the agent doesn't know. The 'that you're not familiar with' clause implies trying your own knowledge first, but no alternative tool is named and there are no explicit exclusions against the sibling help tools.

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