Tank Fight의 표준 사양(canonical specification) 을 제공하는 MCP 서버: 필드 및 창 크기, 탱크와 총알 스탯, 생성 규칙, 점수, 조작, 메뉴 동작, AI 전략, 난이도 상승 곡선, 레벨별 파괴 가능한 미로.
로컬 서비스로 포트에서 실행된다. 모든 MCP 클라이언트는 연결하여 제공되는 도구를 확인하고 스펙을 조회할 수 있다 — Java로 게임을 만들든, TypeScript로 만들든, 다른 무엇으로 만들든 상관없다.
두 가지 역할이 있으며, 두 번째는 처음 보기보다 더 중요하다.
1. 독립적인 구현들 간의 일치 유지. 같은 게임을 별도로 작성한 두 빌드는, 아무도 기록하지 않은 숫자가 필요해지는 순간 어긋나기 시작한다. 둘 다 같은 서비스에 탱크 크기가 얼마인지 묻는다면 추측이 사라진다.
2. 모델이 요구사항을 지어내는 것을 막는다. 스펙이 빠뜨린 모든 세부 사항은 AI 코딩 어시스턴트가 조용히 그럴듯한 값을 골라 넘어가는 지점이다 — 총알은 벽에서 멈추는가? 아군끼리 쏠 수 있는가? 플레이어가 라운드 중간에 파괴되면 어떻게 되는가? 모델은 자신이 결정했다는 사실을 거의 언급하지 않는다. 이러한 각 질문은 여기서 답이 제공되므로, 추측 대신 조회가 되며, open_questions는 진정으로 결정되지 않은 것을 명명하여 정직한 답은 "사람에게 물어보라"가 되지 자신만만한 창작이 되지 않는다.
Related MCP server: 17-0 MCP Server
uv 필요.
uv syncuv run server.py그러면 http://127.0.0.1:8082/mcp에서 스펙이 제공된다. 다른 포트에서 수신하려면 --port를, 다른 인터페이스에 바인딩하려면 --host를, stdio만 지원하는 클라이언트용으로는 --stdio를 사용한다.
모든 MCP 클라이언트, 동시에 여러 개도 가능. Claude Code의 경우:
claude mcp add --transport http tank-spec http://localhost:8082/mcp--scope project를 추가하여 작업 중인 저장소에 기록하면, 해당 빌드에서 작업하는 모든 사람이 동일한 스펙을 받는다. 그런 다음 /mcp로 연결을 확인하고, 클라이언트는 서버에 어떤 도구가 있고 어떻게 호출하는지 물어볼 수 있다 — 여기서 클라이언트별로 구성할 것은 없다.
도구 | 답변 |
| 스펙에 무엇이 있는지, 각각 한 줄씩 — 여기서 시작 |
| 한 섹션, 또는 |
| "X가 발생하나요?" — 이를 결정하는 규칙을 찾아줌 |
| 레벨 N의 의미: 총 적 수, 최대 동시 수, 생성 간격, 어떤 미로인지 |
| 해당 레벨의 벽돌 배치를 타일로 확장하고 ASCII 그림과 함께 반환 |
| 스펙이 의도적으로 결정하지 않은 것 |
이 서버는 누가 연결했는지, 무엇을 만들고 있는지 전혀 알지 못하며, 그것은 의도적이다. 서버는 스펙에 대해 알고 있고, 클라이언트는 서버에 대해 안다. 반대 방향을 가리키는 것은 없다.
따라서 구현이 여전히 스펙과 일치하는지 확인하는 것은 클라이언트의 몫이다. 클라이언트는 자신의 코드에서 값을 읽어 이 도구들이 반환하는 값과 비교할 수 있다 — 클라이언트는 해당 저장소 안에 있고 서버는 그렇지 않다. 체크아웃된 코드에 접근하여 검사하는 서버는 언어, 파일 구조, 경로를 알아야 하며, 다른 구현이 등장할 때마다 업데이트가 필요할 것이다.
같은 이유로 스펙이 파일로 배포되는 대신 서비스로 제공되는 것이다:
모든 구현의 외부에 있다. 한 저장소에서 작업하는 세션은 다른 저장소의 파일을 읽을 수 없지만, 서비스를 호출할 수는 있다.
덤프가 아닌 조회다. search_spec("friendly fire")는 하나의 규칙을 반환한다. 한 가지 질문에 답하기 위해 전체 스펙을 모델의 컨텍스트에 로드하는 것은 정확히 이 방식이 피하는 낭비다.
일부 답변은 저장된 것이 아니라 계산된다. 레벨은 상승 공식에서 생성된다 — 레벨 6은 어떤 파일에도 존재하지 않는다. resolve_level이 물어보는 유일한 올바른 방법이며, 그 정수 절삭(integer truncation)은 중요한 역할을 한다: 부동소수점 버전은 8개 레벨 중 4개에서 불일치한다.
경계선 안의 모든 것은 벽돌이며, 벽돌은 쏘아 없앨 수 있다 — 양쪽 모두 가능하다. 진영은 탱크에게는 중요하지만 벽에는 결코 중요하지 않기 때문이다. 타일은 20x20이고 40의 피해를 받으므로, 표준 총알 두 발이 구멍을 내면 탱크가 그곳을 통과한다. 경계선 자체는 면역이다.
각 레벨에는 고유한 미로가 있으므로, 레벨 번호가 유일한 난이도 조절 장치다: 적이 몇 명 도착하는지, 얼마나 빠르게 도착하는지, 그리고 도착하는 지형까지 설정한다. 레벨 1은 거의 열려 있고, 레벨 8은 길을 찾는 것보다 길을 쏘아 뚫는 것이 보통 더 빠를 정도로 빽빽하다.
get_maze(level)은 사각형, 확장된 타일 목록, 그림을 반환한다:
########################################
#EE................EE................EE#
#EE................EE................EE#
#......................................#
#......BBBBBBBBBBB....BBBBBBBBBBB......#
...
#.............AA...AA...AA.............#
########################################사각형을 직접 확장하지 말고 확장된 타일을 사용하라 — 그 단계와, 총알이 두 타일에 걸쳐 있을 때 어느 타일에 피해를 입히는지에 대한 규칙이, 두 빌드가 같은 사격에서 서로 다른 구멍을 파게 되기 가장 쉬운 지점이다.
미로를 추가하는 것은 YAML의 mazes.levels 아래에 사각형을 추가하는 것뿐이다. 그러면 테스트 스위트가 레벨을 플레이 가능하게 만드는 불변 조건을 검증한다: 타일에 정렬되고, 영역 안에 있으며, 겹치지 않고, 생성 지점과 아군 상자가 비어 있으며, 모든 진입점이 아무것도 파괴하지 않고 도보로 도달 가능해야 한다 — 파내는 것은 지름길이지 요구사항이 아니다.
spec/game-spec.yaml이 전부이며, 손으로 편집하도록 되어 있다 — 그것이 핵심이다. 서버는 호출할 때마다 다시 읽으므로, 변경 사항은 아무것도 재시작하지 않고 즉시 적용된다.
스펙은 작동하는 구현에서 시드되었으며, 그 시점부터 구현과 독립적이다. 스펙이 앞선다: 여기서 값을 먼저 변경한 다음 구현들이 따르게 하라.
uv run pytesttests/test_spec.py는 스펙의 값을 고정하고 모든 미로를 플레이 가능성 불변 조건에 맞춰 검증한다. tests/test_server.py는 MCP 클라이언트를 통해 서버를 구동한다 — 도구를 발견하고, 설명을 읽고, 호출한다. tests/test_http.py는 실제 프로세스를 포트에서 시작하고 클라이언트가 하는 것처럼 HTTP로 연결한다.
spec/game-spec.yaml the specification — the actual source of truth
server.py MCP server: tool definitions, their descriptions, and the transport
tank_spec/spec.py loading, searching, level maths, maze expansion
tests/ spec and maze invariants, MCP integration, HTTP transportGet a level's brick layout: the rectangles, and those rectangles expanded into the exact 20x20 tiles the level starts with.
Every level has its own maze, and all of the brick in it is destructible — bullets from either side chew through it, so the terrain changes as a round is played. Border walls are separate and indestructible.
Use the expanded tile list rather than expanding the rectangles yourself: that expansion is the step two implementations most easily get subtly different, and a one-tile disagreement changes which shots open a route.
Args: level: The level number. Out-of-range values are clamped. ascii_map: Include a picture of the layout — '#' border, 'B' brick, 'E' enemy entry point, 'A' ally start. Useful for checking a build renders the level you think it does; set false to save context.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | ||
| ascii_map | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that all bricks are destructible and terrain changes during play, and that border walls are indestructible. It also notes that out-of-range level values are clamped, which is a behavioral trait. However, it doesn't mention the return format or any potential side effects, but given the tool is a read operation, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening, a rationale for using the expanded tiles, and a concise Args section. Every sentence adds value, and it's appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown but mentioned), the description doesn't need to explain return values. It covers the key aspects: what the tool returns, why to use it, parameter semantics, and behavioral notes. The description is complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'level' parameter (level number, out-of-range clamped) and 'ascii_map' (include a picture, useful for checking build, set false to save context). This adds meaning beyond the schema's basic types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to get a level's brick layout as rectangles and expanded 20x20 tiles. It specifies the resource (level maze) and the action (get), and distinguishes it from siblings by focusing on the brick layout, while siblings like list_sections and get_spec handle other aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using the expanded tile list rather than expanding rectangles manually, explaining the risk of subtle differences. It also provides guidance on when to set ascii_map to false to save context, and mentions that border walls are separate and indestructible, which helps the agent understand the tool's output.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one section of the Tank Fight specification as JSON.
Use this to get the authoritative numbers and rules before implementing a feature — screen size, tank and bullet stats, wall layout, controls, AI parameters, and so on. Do not infer these values from an existing implementation and do not invent them; this file is what the implementations are supposed to agree with.
Args: section: A section name from list_sections, or a dotted path to go straight to a value, e.g. "entities.bullet" or "ai.enemy.turn_chance_per_tick".
| Name | Required | Description | Default |
|---|---|---|---|
| section | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds crucial context: the spec is authoritative, and it explicitly warns against inferring values from existing implementations. However, it does not mention error handling or behavior for invalid section names, so it's not fully transparent on edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with a clear one-sentence summary followed by usage guidance and a well-formatted Args section. Every sentence adds value, and the formatting makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with an output schema, the description is complete: it explains the purpose, parameter format, and authoritative nature of the data. It appropriately references list_sections for valid section names and provides examples of dotted paths. No additional return-value details are needed given the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only declares 'section' as a string with no description, so the description provides all parameter semantics. It explains that the value can be a section name from list_sections or a dotted path, with concrete examples like 'entities.bullet'. This is essential information not available from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Return one section of the Tank Fight specification as JSON,' which is a specific verb+resource statement. It also explains the use case ('before implementing a feature') and distinguishes itself from sibling tools by focusing on retrieving a named section of the specification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states when to use the tool ('before implementing a feature') and warns against inferring or inventing values, which provides strong context. However, it does not explicitly name alternative tools or exclusions beyond referencing list_sections for section names, so it stops short of the explicit alternative guidance found in a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the sections of the Tank Fight specification, with a one-line summary of each, so you can fetch only the part you need.
Start here when you don't yet know where a rule lives. Fetching the whole spec is rarely necessary and wastes context.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It clearly discloses that the tool returns a section list with summaries rather than full content, and frames itself as a navigation helper. For a simple read-only listing tool, this is sufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and every phrase earns its place. It avoids filler while adding practical usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool with an output schema, the description is complete: it says what the tool returns, why to use it, and when to start with it. It sufficiently covers the low-complexity context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is effectively 100%, so no parameter explanation is needed. The baseline of 4 applies because there is no param information to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('List the sections'), the resource ('Tank Fight specification'), and the output form ('with a one-line summary of each'). It also differentiates from siblings by positioning this as the starting point for locating rules before fetching a specific part.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit guidance: 'Start here when you don't yet know where a rule lives' and warns that 'Fetching the whole spec is rarely necessary and wastes context.' It lacks an explicit contrast with search_spec, which is a sibling that may be a better alternative when users know search terms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the design decisions the specification deliberately has NOT made.
Check this before inventing an answer to something the spec is silent on. If your question is here, the honest answer is "not decided yet" — say so and ask, rather than picking something and moving on. Anything on this list is a place where two implementations will otherwise diverge.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context: the tool returns a list of open items and hints that these are places where implementations diverge. However, no annotations are provided, so the description carries the burden. It does not state whether the list is static or generated, or any caching/rate limits, but for this kind of read-only tool, it is adequate. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short paragraphs, each earning its place: purpose, timing, action on hit, consequence. No fluff, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool, the description fully explains when and how to use it and what it returns. It doesn't describe output format, but an output schema exists, so that's not needed. It is complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the description has little to add. The description explains what the output represents (open design decisions), adding semantic meaning beyond the empty schema. Baseline for 0 params is 4, and it meets that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists design decisions left open by the specification. It uses specific verb 'List' and resource 'design decisions', and distinguishes it from sibling tools like list_sections or get_spec by focusing on unresolved questions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: check this tool before inventing an answer, and what to do if a question is here (say 'not decided yet' and ask). It implies when not to use (when question is not listed, it may be intentionally handled elsewhere).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve what a level number actually means: how many enemy tanks the round fields in total, how many may be alive at once, and how often they arrive.
Levels are GENERATED from a ramp formula, not stored anywhere, so this cannot be answered by reading a file — call this tool instead of computing it yourself, because the formula truncates with integer division and a floating-point version disagrees at several levels.
The result also names the level's maze; call get_maze for its actual layout.
Args: level: The level number. Out-of-range values are clamped to the supported range rather than rejected.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals important traits: integer division with truncation, potential disagreement with floating-point calculations, and clamping behavior for out-of-range values. It also states what the result includes without exposing unnecessary details. This goes beyond a generic description and provides genuinely useful edge-case information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise, with a clear lead sentence, a paragraph explaining rationale, and a compact Args section. Every sentence earns its place—no filler or redundancy. The structure (purpose, why, related tool, parameter details) is logical and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description covers all necessary aspects: what it computes, why it's needed, how parameters behave, and what the output references (maze). It does not omit critical context and does not need to detail return types because an output schema is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for the 'level' parameter (0% coverage), so the description must compensate. The Args section does this effectively by explaining the parameter's meaning and its clamping behavior, which is not present in the schema. This fully addresses potential confusion and guides correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Resolve') and a detailed resource ('what a level number actually means: how many enemy tanks the round fields in total, how many may be alive at once, and how often they arrive'). It distinguishes itself from siblings by mentioning get_maze for maze layout and contrasting with reading a file. This is more than just a restatement of the name—it provides concrete capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool instead of alternatives: 'Levels are GENERATED from a ramp formula, not stored anywhere, so this cannot be answered by reading a file — call this tool instead of computing it yourself'. It also directs to a sibling ('call get_maze for its actual layout'). This gives clear decision guidance, exceeding basic when-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the specification for the rule or value that answers a question.
Use this whenever you are about to assume how the game behaves — "do bullets stop at walls?", "can allies shoot each other?", "how fast is a bullet?", "what happens when a player is destroyed?". Searching costs far less context than loading whole sections, and the answer is authoritative.
If the search comes back empty, the spec may genuinely not cover it: check open_questions() before deciding anything yourself.
Args: query: Plain words describing what you need, e.g. "friendly fire" or "spawn interval" or "health bar colour".
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explains the tool is a read-only search ('costs far less context than loading whole sections') and the behavior on empty results (spec may not cover it, check open_questions). This adds transparency about the search's scope and fallback, though it doesn't detail return format or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise, using a short intro, a usage guideline paragraph, and a parameter explanation. Every sentence adds value, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and the description covers purpose, usage, fallback behavior, and parameter semantics. The output schema exists, so return values don't need explanation. It is complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'query' parameter with examples: 'Plain words describing what you need, e.g. "friendly fire" or "spawn interval" or "health bar colour".' This adds meaningful guidance beyond the schema's bare string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search the specification for the rule or value that answers a question.' It uses a specific verb ('search') and resource ('the specification'), and provides concrete examples of questions it answers, distinguishing it from sibling tools like list_sections or get_spec.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly guides when to use this tool: 'Use this whenever you are about to assume how the game behaves'. It contrasts with alternatives by noting that searching costs less context than loading whole sections. It also provides a clear fallback: if the search comes back empty, check open_questions() before deciding anything yourself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_mazeget_speclist_sectionsopen_questionsresolve_levelsearch_specScored across 6 tools
Each tool has a distinct purpose: listing sections, getting a section, searching the spec, resolving level semantics, retrieving maze layouts, and listing open questions. No overlaps or ambiguity.
All tool names follow a consistent verb_noun pattern (list_, get_, search_, resolve_, open_), making the API predictable and easy to navigate.
Six tools is well-scoped for a specification server, covering all necessary access patterns without unnecessary redundancy or bloat.
The tool set fully covers the domain: discovering, retrieving, searching, interpreting, and visualizing spec details, plus handling open questions. No obvious gaps.
Read-only MCP server for the OPERANT AI operating-agent calibration benchmark.
Read-only MCP server for the WebAssembly spec: instructions, types, sections, search, proposals.
Public, read-only MCP server for FarmNeural company facts, packages, and capabilities.
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.