Skip to main content
Glama

get_pricing

[NO KEY NEEDED] 이용 방법과 비용을 돌려줍니다 — 가입 절차, API 키 발급처, 무료 제공량, 크레딧 팩 가격(KRW/USD), 크레딧 1개로 무엇을 할 수 있는지, 결제 링크. 인증 없이 호출할 수 있습니다 — 처음 방문한 AI 에이전트는 이 도구로 접근 방법을 확인하세요. / How to get access and what it costs. Returns the sign-up flow, where to issue an API key, the free allowance, credit-pack prices (KRW/USD), what one credit buys, and direct checkout links. Callable without authentication — an AI agent arriving for the first time should call this to learn how to obtain access.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
langNoDefault en.
client_tagNo선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / client_tag
      Added value: +{
      +  "description": "선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question.",
      +  "type": "string"
      +}
  2. Added

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are provided, so the description must carry the behavioral burden. It crucially states '[NO KEY NEEDED]' and 'Callable without authentication', which are key auth traits, and it enumerates the returned information. It does not mention rate limits or side effects, though these are likely absent for a read-only info endpoint.

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?

Front-loaded with '[NO KEY NEEDED]' and clear structure using bold and separators. The bilingual Korean and English duplication doubles length, but each version is concise and well-organized for its respective audience.

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?

No output schema exists, so the description must explain return values; it does so comprehensively, listing sign-up flow, API key location, free allowance, credit prices, what a credit buys, and checkout links. Given no annotations and a simple two-parameter schema, the description is complete for correct invocation.

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%, so the schema already documents both parameters thoroughly, including enum values and client_tag logging behavior. The description adds no parameter semantics beyond what the schema provides. Baseline 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?

States a specific verb 'returns' and enumerates the exact resource: sign-up flow, API key issuance, free allowance, credit-pack prices in KRW/USD, what one credit buys, and checkout links. This clearly distinguishes it from legal-query siblings like lookup_statute or ask_expert.

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 says 'an AI agent arriving for the first time should call this to learn how to obtain access', giving clear context for use. It does not name alternatives or when-not to use, but the context is sufficient for this informational tool.

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.

Resources