Skip to main content
Glama

MyFSS

by kr.eocpa

사용량 통계

get_usage_stats
Read-onlyIdempotent

MyFSS 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds substantial behavioral context beyond that: tiering by requester (admin/local stdio vs. public), what fields exist only at operator tier, that absence of users/top_targets does not mean zero, that user is a truncated SHA-256 token hash rather than a person, and that timings are server-side only. This is rich transparency.

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 organized into Purpose, Usage, Response, and Rules sections, with all information necessary for a no-output-schema tool. Every section earns its place; the response shape and tier rules are critical since no output schema exists. It is detailed without being redundant.

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?

For a read-only, single-parameter statistical tool with no output schema, the description covers everything an agent needs: what data is returned, how the response varies by visibility tier, the meaning of days values, and edge-case semantics such as stdio calls never appearing. Nothing essential is missing.

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 input schema already documents days (default 30, 0 means full period), so coverage is 100%. The description adds value by giving concrete natural-language triggers and clarifying the meaning of days=0 versus the default. This is helpful, though the schema already carries the core semantics.

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: 'MyFSS MCP의 get_usage_stats 도구는 이 MCP 서버의 도구 사용량 통계를 반환합니다' and lists the exact metrics (per-tool usage, latency percentiles, error rate, daily trend). This clearly differentiates it from the document-focused siblings (get_document, list_recent, list_tags, search_documents).

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 a dedicated Usage section with natural-language mappings to the days parameter: recent 30 days → no argument, last 7 days → days=7, full period → days=0. It gives clear context for when to call with each value, though it does not explicitly discuss when to choose this tool over sibling alternatives.

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

All MyFSS toolsInspect
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

A4.7/5.0
Disambiguation4/5

Each tool has a distinct role: search_documents handles query-based search with pagination, list_recent is the no-query recent feed, list_tags supplies filter vocabulary, get_document retrieves full text, and get_usage_stats is server telemetry. The only mild overlap is between list_recent and a query-less search_documents, but the descriptions explicitly separate quick skim from fuller search.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern: get_document, get_usage_stats, list_recent, list_tags, search_documents. The naming is predictable and makes the purpose of each tool immediately clear.

Tool Count5/5

Five tools is well-scoped for a read-only regulatory document search and retrieval server. The set covers discovery, search, vocabulary validation, full-text access, and usage monitoring without redundant or excessive tools.

Completeness5/5

The core workflow is fully covered: discover documents via search or recent listing, validate filter values via list_tags, and retrieve full text with pagination via get_document. Since this is a read-only corpus, the absence of create/update/delete tools is appropriate rather than a gap.

Resources