Read-only MCP server for the WebAssembly spec: instructions, types, sections, search, proposals.
Fetch one WebAssembly instruction by mnemonic (i32.add) or binary opcode (0x6a, multi-byte 0xfd 0x89 0x02): opcode bytes, category, introducing version, stack type signature, validation/execution anchors + URLs, and traps (runtime trap conditions with canonical names; empty + can_trap:false when it never traps).
| Name | Required | Description | Default |
|---|---|---|---|
| opcode | No | Binary opcode hex, e.g. `0x6a` or `0xfd 0x89 0x02`. Exact. | |
| mnemonic | No | Instruction mnemonic, e.g. `i32.add`. Case-insensitive, exact. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant context beyond readOnlyHint: true by detailing the full return payload (opcode bytes, category, version, signature, anchors, traps). No contradiction with annotations.
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 a single, long sentence that front-loads the action. It is concise but could be slightly restructured for readability (e.g., splitting into two sentences).
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?
With no output schema, the description thoroughly explains return fields, fulfilling the need for the agent to understand what the tool returns. No gaps remain.
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 coverage is 100% and both parameter descriptions are adequate. The description does not add substantial meaning beyond what the schema already provides, so baseline 3 is appropriate.
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 uses specific verbs ('Fetch') and resources ('WebAssembly instruction'), clearly distinguishing the tool from siblings like instruction_list and instruction_search by focusing on a single instruction lookup by mnemonic or opcode.
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 implies use when a specific mnemonic or opcode is known, but it does not explicitly state when to use this tool over alternatives (e.g., instruction_search for partial matches) nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enumerate WebAssembly instructions, filterable by category, introduced_in (1.0|2.0|3.0), mnemonic prefix, and can_trap (only trapping / only non-trapping). Rows (incl. can_trap) sorted by opcode.
| Name | Required | Description | Default |
|---|---|---|---|
| prefix | No | Mnemonic prefix, e.g. `i32.`. Case-insensitive. | |
| can_trap | No | Keep only instructions that can (true) / cannot (false) trap. | |
| category | No | Instruction category. | |
| introduced_in | No | Introducing version. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation readOnlyHint already signals safety; description adds sort order and inclusion of can_trap, but no details on pagination, rate limits, or output structure.
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?
Single sentence with verb front-loaded, minimal but informative, no wasted words.
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?
Missing output schema, but description mentions key output fields (can_trap, opcode sort). For a filterable list with 4 optional params, it's largely complete.
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 coverage is 100%, so description adds modest value (e.g., prefix case-insensitivity, enum listing), but no deep semantics beyond schema.
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?
Description states a specific verb 'Enumerate' and resource 'WebAssembly instructions', lists all filterable parameters, and distinguishes from siblings like instruction_search and instruction_get by focusing on listing with filters.
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?
No explicit when-to-use or when-not-to-use guidance relative to siblings, but the filtering capabilities imply its role as a listing tool against a single instruction or search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranked free-text search across instruction mnemonics, categories, and opcode hex. Returns hits with a matched_on field.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max hits. | |
| query | Yes | Search text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds that search is ranked and results include `matched_on` field, which is helpful for understanding output. No additional behavior like pagination is mentioned, but it's adequate for a simple read-only tool.
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?
Two sentences, no wasted words, immediately conveys purpose and key output field. Ideal length.
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 search tool with 2 parameters and readOnly annotation, the description provides necessary context: what is searched, that results are ranked, and the key output field. Could mention result limiting via limit param, but schema covers that. Overall sufficient.
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 coverage is 100%, so baseline is 3. Description adds value by specifying the fields searched (mnemonics, categories, opcode hex) and that results are ranked, which enhances understanding of the query parameter beyond its schema description.
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?
Clearly states it performs ranked free-text search across specific fields (mnemonics, categories, opcode hex) and returns hits with a `matched_on` field. Differentiates from sibling tools like instruction_get and instruction_list by being a search tool.
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?
Implies usage for searching by text but lacks explicit guidance on when to use versus alternatives like instruction_list. Could mention that it's for flexible text queries rather than exact matches or listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List WebAssembly proposals + phases. Filter by status (phase-0…phase-5, finished, inactive), phase (0–5), champion, affects (core|js-api|web-api), or contains.
| Name | Required | Description | Default |
|---|---|---|---|
| phase | No | Numeric phase 0–5. | |
| status | No | Lifecycle status. | |
| affects | No | Affected spec (finished only). | |
| champion | No | Champion substring. | |
| contains | No | Name/champion substring. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds filter details, which are already in the schema, but does not disclose other behaviors like return format or pagination.
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 a single, well-structured sentence that front-loads the purpose and then lists filters. No unnecessary words.
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 listing tool with 0 required parameters and all filters described, the description is mostly complete. It lacks details about return format or pagination, but these are typical for list tools.
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 100%, so the schema already explains parameters. The description repeats some values but does not add new semantic meaning beyond what the schema provides.
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 it lists WebAssembly proposals and phases, and explicitly mentions filtering options. It is specific and distinct from sibling tools like spec_search or instruction_list.
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 lists available filters but does not explicitly state when to use this tool versus alternatives. However, the context is clear as the tool is the only one for listing proposals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one spec clause by id or anchor across core / js-api / web-api (syntax-numtype, valid-unreachable, modules, streaming-modules, …): title, prose, cross-references, SpecTec formal refs, and rendered URL.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Clause id or anchor. | |
| spec | No | Which spec (default core). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates no side effects. The description adds value by detailing what is returned (title, prose, cross-references, etc.), providing behavioral context beyond the annotation.
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 a single sentence that front-loads the action and key details. It is slightly long due to examples but remains efficient and structured.
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 no output schema, the description partially explains return data (title, prose, etc.) but not the structure. The param count and annotation coverage are good, but the description could be more complete about the output format.
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 coverage is 100%, so baseline 3. The description provides example clause ids and spec options, adding marginal semantic context beyond the schema's parameter descriptions.
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 action 'Fetch one spec clause by id or anchor' and specifies the scope across three specs, listing the included data (title, prose, etc.). It distinguishes from siblings like 'section_list' which lists sections, and 'instruction_get' which fetches instructions.
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 explains what the tool does but does not provide explicit guidance on when to use it versus alternatives. It implies use when fetching a single clause, but no 'when-not' or sibling tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Navigate the clause tree of a spec (core / js-api / web-api), filterable by source path (syntax, valid, exec, binary, text, appendix), anchor_prefix, titled_only, and max_level.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Source path / prefix. | |
| spec | No | Which spec (default core). | |
| max_level | No | Cap heading depth. | |
| titled_only | No | Drop anchor-only blocks. | |
| anchor_prefix | No | Id/anchor prefix. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds context by stating it navigates (implies traversal, not just listing) and filters by various parameters. No contradictions.
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?
Single sentence with a dash-separated list. Front-loaded with main purpose. Could be slightly improved with better punctuation (e.g., parentheses for list). Efficient overall.
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?
No output schema, so description should hint at return format (tree structure). It does not. Also lacks mention of sorting or pagination. However, parameter details are comprehensive enough for a read-only navigation 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 coverage is 100%, so baseline is 3. The description adds meaning beyond the schema: it explains 'path' as source path/prefix, lists spec enums, caps heading depth with max_level, drops anchor-only blocks with titled_only, and identifies anchor_prefix as id/anchor prefix. This fully compensates for any schema brevity.
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 uses a specific verb ('Navigate') and clearly identifies the resource (clause tree of a spec). It lists available specs and filter options, distinguishing it from siblings like 'section_get' (single section) and 'instruction_list' (different resource).
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 implies usage for exploring or filtering the clause tree but does not explicitly state when to use this tool versus alternatives like 'section_get', 'spec_search', or 'instruction_list'. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across clause anchors, titles, and prose of a spec (core / js-api / web-api). Ranked anchor-exact > title > anchor > prose, with snippets for body matches.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | No | Which spec (default core). | |
| limit | No | Max hits. | |
| query | Yes | Search text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. The description adds behavioral details beyond annotations: ranking order (anchor-exact > title > anchor > prose) and snippet generation for body matches. This informs the agent of search behavior and result structure.
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 with no wasted words. The core action is stated first, followed by additional behavioral details (ranking, snippets). It is concise, front-loaded, and each sentence adds value.
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 description covers input (search across spec parts) and behavioral details (ranking, snippets). Without an output schema, it does not specify return fields, but the mention of snippets and ranking provides some expectation. The limit parameter suggests pagination is handled, though not explicitly detailed.
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 coverage is 100% with descriptions for all three parameters. The description repeats the spec enum values but does not add meaningful new semantic information beyond what the schema already provides, meeting the baseline for fully documented schema.
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 it performs full-text search across specific parts of a spec (clause anchors, titles, prose) and names the allowed spec values. The verb 'search' and resource 'spec' are explicit, differentiating it from sibling tools like instruction_search or section_get.
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 implies usage for searching spec content, and the mention of spec values provides context. It does not explicitly state when not to use or name alternatives, but the sibling tool list (e.g., instruction_search for instructions, section_get for sections) makes the distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return this server's package version plus the pinned upstream commit SHA(s) the bundled data was indexed from.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds what is returned but no additional behavioral context like auth requirements or side effects. Acceptable for a simple read tool.
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?
Single sentence with no wasted words. Front-loaded with the action and key outputs.
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 tool with no output schema, the description completely specifies what the tool returns. No gaps.
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?
No parameters, baseline 4 per rubric. Description adds no parameter info since there are none.
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?
Description clearly states it returns the server's package version and pinned upstream commit SHA(s). Verb 'return' with specific resources, distinguishing it from sibling tools that deal with instructions, proposals, sections, etc.
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 implies usage when needing version info, but lacks explicit guidance on when not to use or alternatives. Given simplicity, it's adequate but not proactive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a value type (i32, funcref, v128, …) or type form (functype, limits, memtype, …): classification, sibling members, defining clause prose, formal refs, and URL.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Type or type-form name. Case-insensitive, exact. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint: true, so the agent knows it's a safe read. Description adds details on return content (classification, sibling members, prose, refs, URL), which provides useful context beyond annotations.
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?
Single sentence with colon list is highly concise and front-loaded with purpose. No unnecessary words.
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?
Despite no output schema, description explicitly lists what is returned, making it complete for a simple read-only tool with one parameter.
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 100% with clear definition of 'name' parameter. Description adds example values but does not significantly enhance parameter understanding beyond the schema.
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?
Description uses specific verb 'look up' and clearly identifies resource types (value types and type forms) with examples. It distinguishes from sibling tools like instruction_get by focusing on type information.
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?
Description implies usage for looking up types but lacks explicit when-to-use or when-not-to-use guidance. No comparison to alternatives is provided.
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. Dates show when Glama detected each change.
instruction_getinstruction_listinstruction_searchproposal_listsection_getsection_listspec_searchspec_versiontype_getClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Independent MCP server for the TC39 specs (ECMA-262 + ECMA-402): clauses, search, diffs, history.
Read-only MCP server for the OrchestKit docs: full-text search + Markdown fetch. No auth.
MCP server for hex.pm and hexdocs.pm: search, inspect, compare, and audit Elixir packages
Add one secure layer between your agents and this server.
Each tool targets a distinct aspect of WebAssembly: instructions (get/list/search), proposals (list), spec sections (get/list/search), version info, and types. No overlapping purposes.
All tools use consistent snake_case with verb_noun pattern: instruction_get, instruction_list, instruction_search, proposal_list, section_get, section_list, spec_search, spec_version, type_get.
9 tools is well-scoped for a WebAssembly reference server, covering instructions, specs, proposals, types, and metadata without being overwhelming.
Covers core retrieval and search for instructions, specs, proposals, and types. Minor gaps like no dedicated proposal get or type list, but the set is sufficient for typical exploration tasks.
