Skip to main content
Glama

fetch_problem_content_programmers

Fetch a Programmers problem's full content: title, description, constraints, and input/output examples, using its problem ID or URL.

Instructions

프로그래머스 문제 본문 스크래핑.

프로그래머스 페이지에서 문제 제목, 설명, 제한사항, 입출력 예시를 가져옵니다.

응답 구조: problemId, title, description, inputFormat, outputFormat, examples, limits, metadata

사용 시나리오:

  • 문제 풀이 전 문제 본문 확인

  • 코드 분석 시 문제 요구사항 비교

제한사항:

⚠️ 플랫폼 판별: 문제 번호만 입력된 경우 대화 맥락에서 플랫폼을 파악하거나, 맥락이 없으면 반드시 BOJ/프로그래머스 중 어느 플랫폼인지 사용자에게 확인 후 호출하세요.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
problem_idYes프로그래머스 문제 ID 또는 URL
Behavior5/5

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

With no annotations provided, the description carries the full burden and does well: it discloses the target URL, timeout, retry limit, cache duration, and a critical platform-disambiguation warning. This is rich behavioral context beyond the tool name and schema.

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?

The description is well-structured with clear sections and front-loaded main purpose. It includes useful details without excessive fluff, though a few lines could be trimmed without losing important guidance.

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?

Despite having no output schema, the description lists the response structure and key behavioral constraints (timeout, retries, cache). The single parameter is adequately explained, and the platform ambiguity warning addresses a real contextual risk.

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%, and the description adds that the parameter accepts either a problem ID or a URL. It also clarifies the meaning of the problem_id parameter in the context of the scraping target, going beyond the schema's generic type definition.

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 it scrapes Programmers problem content including title, description, constraints, and examples. It identifies the specific resource and targets the Programmers platform, distinguishing it from sibling BOJ tools.

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?

It gives explicit use scenarios (before solving, during code analysis) and importantly instructs to verify the platform when only a problem ID is given. It doesn't explicitly name sibling alternatives, but the platform verification guidance effectively prevents misuse.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/itsme-shawn/algoKit-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server