Skip to main content
Glama

MyKIFRS

사용량 통계

get_usage_stats
Read-onlyIdempotent

MyKIFRS MCP의 get_usage_stats 도구는 이 MCP 서버의 도구 사용량 통계를 반환합니다.

[Purpose]

  • Per-tool usage·latency (avg/percentiles)·error rate·daily trend.

[Usage]

  1. "최근 30일 사용량" → (인자 없음)

  2. "지난 7일만" → days=7

  3. "전체 기간" → days=0

[Response]

  • Both tiers: { visibility, period:{days, since, until}, overview:{total_calls, unique_users, errors, error_rate, p50_ms, p90_ms, p99_ms}, by_tool:[{tool, calls, errors, error_rate, avg_ms, p99_ms, users}], by_day:[{day, calls}] }

  • visibility="public" adds note; period.days = "all" when days=0.

  • visibility="operator" adds users:[{user, is_owner, calls, distinct_tools, first_seen, last_seen, tools:[{tool, calls, avg_ms}]}] and top_targets:[{target, tool, calls, users}].

[Rules]

  • Tier by requester: admin token·local stdio → "operator", else "public".

  • users·top_targets exist only at operator tier — absence ≠ 0.

  • user is a truncated SHA-256 of the 접속 토큰 — not a person. stdio calls (no hash) never appear.

  • Timings = server-side handler time (no network).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNo최근 N일 윈도 (0이면 전체 기간, 기본 30)

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Even though annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, the description adds substantial behavioral context: the public vs operator tier distinction, that users/top_targets are omitted at public tier where absence is meaningful, that user IDs are truncated SHA-256 hashes of tokens rather than person identifiers, and that timings are server-side handler times. This goes far beyond the annotations.

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?

The description is well-organized into Purpose, Usage, Response, and Rules sections, with the main purpose front-loaded first. Although it is longer than average, every section earns its place by adding operational detail that the schema and annotations do not provide, and it avoids redundancy.

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?

With no output schema, the description fully compensates by specifying the complete response shape for both tiers, including field-level detail for overview, by_tool, by_day, users, and top_targets. It also covers tier determination, privacy implications of hashed users, and timing semantics, making the tool fully callable and interpretable by an agent.

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?

The schema already documents days with 100% coverage, including default 30 and 0 meaning the full period. The description adds practical usage mapping and clarifies that period.days becomes 'all' when days=0, which enriches the parameter's meaning beyond the raw 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 returns usage statistics for the MCP server, with a specific bulleted list of what it measures: per-tool usage, latency percentiles, error rate, and daily trends. Sibling tools are all content lookups (paragraphs, QNA, standards), so this tool is unambiguously distinct as a metrics/statistics tool.

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?

The description gives explicit natural-language invocation scenarios ('recent 30 days' with no arguments, 'last 7 days' with days=7, 'entire period' with days=0), which clarifies when to call the tool and how to shape the request. It does not name alternatives or exclusions, but no sibling tool offers comparable usage statistics, so this level of guidance is sufficient.

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

A4.8/5.0
Disambiguation5/5

The verb prefixes (get/search/list) plus distinct nouns (paragraph, qna, standards, usage_stats) make each tool's purpose unmistakable. search_standards and search_qnas target different corpora, and get_paragraph/get_qna retrieve by unique key versus full-text search, so no two tools overlap.

Naming Consistency5/5

Every tool follows the verb_noun snake_case pattern: get/retrieves by key, search/does full-text queries, list/returns the catalog. The naming perfectly mirrors the tool behavior, making the set predictable and easy to navigate.

Tool Count5/5

Six tools is well-scoped for a standards/Q&A reference server: catalog (list_standards), full-text search over two corpora (search_standards, search_qnas), keyed retrieval for each (get_paragraph, get_qna), and one telemetry tool. Each tool earns its place with no redundancy.

Completeness4/5

The core retrieval workflow is complete: list catalog → search corpus → fetch full text, and search Q&A → fetch Q&A response, with get_paragraph even linking to related Q&As. Minor gaps exist such as no way to browse a standard's full paragraph structure or enumerate Q&A documents without a search query, but agents can work around these.

Resources