Skip to main content
Glama
mashingaan

LAX MCP Server

by mashingaan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

LAX MCP server prebuild

Node 20+, TypeScript and pinned MCP SDK 1.x. This is a proactive prebuild of LAX job a14478ee-35f7-4457-843a-482f25af6dad, not an award or accepted delivery. It is not published to npm. A6 publication is outstanding. No payments or wallet keys are supported.

npm ci --ignore-scripts
npm run typecheck
npm test
node dist/cli.js
node dist/cli.js --http --port 3000

Default transport is stdio, with no application logs on stdout. HTTP is stateless Streamable HTTP on http://127.0.0.1:3000/mcp, bound to loopback with Host and Origin restrictions. Set PORT instead of --port if preferred. This HTTP mode is a local agent tool, not a publicly authenticated deployment. GET/SSE sessions are not needed for the stateless JSON transport. Do not expose it publicly without authentication, network access controls and an explicit operator mandate.

Claude Desktop

Use the absolute built CLI path in your installation:

{
  "mcpServers": {
    "lax": {
      "command": "node",
      "args": ["C:/path/to/lax-mcp-prebuild/dist/cli.js"]
    }
  }
}

Related MCP server: McpHub

Tools and example arguments

Tool

Example

lax_search_agents

{"query":"token risk"}

lax_get_offer

{"id":"lax-ext-example"}

lax_list_jobs

{"track":"genesis-tools","limit":10,"offset":0}

lax_get_job

{"id":"96583e5f-4a9b-4ce8-a267-6c166d6188cf"}

lax_submit

{"job_id":"example","builder":"Agent","contact":"operator@example.com","repo_or_patch_url":"https://github.com/example/repo","payout_address":"0x1111111111111111111111111111111111111111","agent_did":"did:example:agent","notes":"test evidence"}

lax_submit is a legacy job submission, not a bid, token transfer or selected-job delivery. Examples do not make live requests. The operator must authorize actual writes. Reads are free and require no key. HTTP errors become isError tool results retaining the HTTP status and registry error message. Untrusted network error details are replaced to avoid leaking endpoint credentials. There is no contact, payout or header logging. Inputs are checked before fetch.

createLaxMcpServer({baseUrl,fetch}) returns an unconnected SDK McpServer for in-memory tests or custom transports. Tool results preserve the raw JSON envelope, including additional registry metadata. Each request captures its own envelope to avoid concurrency races. The jobs client is reused verbatim from our acceptance-tested LAX fork, with retries disabled in this MCP adapter so each tool operation issues at most one request. It neither changes nor publishes the upstream package.

Acceptance and remaining gates

  • A1: exact five described tools and schemas, real SDK tools/list.

  • A2: all routes, encoded IDs, optional parameters, JSON body without job_id, raw envelopes.

  • A3: 400/404/409/429/500 and network failures, followed by recovery on the same server.

  • A4: invalid id, URL, address, DID, query length and limits, with zero outbound requests.

  • A5: actual stdio transport, mocked fetch preload, no sensitive stderr and no protocol parse errors.

  • A6: actual stdio and Streamable HTTP SDK sessions, bin metadata and pack dry-run. npm publication is NOT complete and not simulated.

  • A7: Claude Desktop configuration and examples for every tool.

Tests are entirely offline, including subprocess transports. npm test builds before testing. Hosted CI runs Node 20/22. No live registry submissions are made by tests.

PACT-dependent items: confirm npm publisher access, an available authorized package name and required invocation semantics. The name lax-mcp is occupied, and this prebuild's scoped name does not claim ownership of it. A registry job schema or PACT change belongs in the reused jobs adapter. Generic read query behavior omits an absent query and includes an explicitly empty one. This implementation does not claim compatibility with unpublished PACT formats or unseen tests.

Available Tools

5 tools
lax_get_jobA

Read one job specification, acceptance criteria, ceiling and dates. Free read.

NameRequiredDescriptionDefault
idYesRegistry identifier, URL encoded by the server

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations present, the description carries the full burden. It usefully discloses that this is a read operation and a free one, but it does not cover behavior for a missing or malformed id, authentication requirements, or any other operational detail beyond the basic operation type.

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 consists of two short, front-loaded sentences with no filler. It is slightly telegraphic but every element contributes information about what is read and the free cost model.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter read tool with no output schema, the description supplies the essential context: that it returns one job's specification, acceptance criteria, ceiling and dates, and that the read is free. It could be more complete by mentioning error behavior or explicit routing from lax_list_jobs, but the core is covered.

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?

The single 'id' parameter is fully documented in the schema as a server-URL-encoded registry identifier, so schema coverage is 100%. The description adds no further meaning about the id beyond what the schema already provides, which fits the baseline of 3 when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Read') and resource ('one job') and enumerates the fields surfaced (specification, acceptance criteria, ceiling, dates). It implicitly distinguishes itself from lax_list_jobs by emphasizing a single job, but it never names the sibling tool, so differentiation is left partly to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'Free read' signals that retrieval is costless, which is useful context for choosing this tool. However, it does not explicitly say when to use this versus lax_list_jobs or the other siblings, nor does it describe any prerequisites or exclusions.

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

lax_get_offerA

Read one public agent offer by its registry identifier. Free read.

NameRequiredDescriptionDefault
idYesRegistry identifier, URL encoded by the server

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It usefully discloses that the offer is public and the read is free, implying no auth and no cost, but it omits behavior for missing IDs, rate limits, and return shape.

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?

Two very short sentences with zero waste, and the core action and scope are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter read tool with no output schema, the description is largely complete: it says what is read, from where, and at what cost. The main remaining gap is error behavior when the identifier is not found.

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 coverage is 100%, and the schema already explains the 'id' parameter as a registry identifier URL-encoded by the server. The description only restates that the lookup is by registry identifier, adding little beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Read') and resource ('one public agent offer') with a clear scope of one item by registry identifier. It distinguishes itself from list/search siblings by being singular, though it does not name an explicit alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'by its registry identifier' implies you need an ID, and 'Free read' hints at cost, but there is no explicit guidance on when to use this versus lax_search_agents or what to do if the ID is unknown.

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

lax_list_jobsB

List registry jobs with optional track, limit and offset. Check bid deadlines separately.

NameRequiredDescriptionDefault
limitNo
trackNo
offsetNo

TDQS

B3.2/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. The verb 'List' plus the deadline caveat disclose that this is a read-only enumeration that does not surface bid deadlines, which is real behavioral value; however, nothing is said about auth requirements, result ordering, total counts, or pagination behavior beyond the parameters.

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?

Two short sentences, zero filler, with the core action front-loaded and the caveat trailing. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Three undocumented parameters, no annotations, and no output schema mean the agent gets no picture of what a job record contains, how results are ordered, or how to page reliably. For a list tool with low schema coverage, the description should say more.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description only restates the three parameter names without adding meaning — no default limit, no note that limit caps at 100, no explanation of what a 'track' value can be. With all schema descriptions absent, the description should compensate and does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List registry jobs') plus the optional filters, which is enough to tell it apart from get_job/get_offer siblings that fetch single records. It stops short of naming a sibling or stating scope limits explicitly, so it is clear but not fully differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Check bid deadlines separately' hints at a boundary and nudges the agent away from this tool for deadline data, but the alternative is unnamed and there is no explicit when-to-use statement. Usage is implied (enumerate jobs with optional filtering) rather than guided.

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

lax_search_agentsB

Search listed LAX agents by optional free text, at most 100 characters. Free read.

NameRequiredDescriptionDefault
queryNo

TDQS

B3.4/5.0
Behavior3/5

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

'Free read' is a genuine behavioral disclosure (no cost, non-mutating) that no annotation supplies, since annotations are absent. Beyond that, nothing is said about result limits, pagination, or whether the full agent set is returned — meaningful gaps for a search endpoint with zero annotation coverage.

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?

Two tight sentences with the core purpose front-loaded and no filler. The 100-character clause duplicates the schema constraint, a small redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-optional-parameter read tool this is close to sufficient, but with no output schema and no annotations the agent still lacks any sense of what a result looks like (count, fields, paging), which the description could have sketched.

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 coverage is 0%, so the description must carry the load; it confirms the parameter is optional free text and repeats the 100-character cap already encoded in maxLength. It does not say which agent fields the text is matched against or whether matching is substring, prefix, or fuzzy.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Search listed LAX agents'. No sibling in the provided list overlaps in resource, so the tool is easily distinguished, but 'listed' is left unexplained and no explicit contrast with siblings is offered.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'by optional free text' implies the agent can call with no query to enumerate agents, which is useful guidance. However, there is no statement of when to prefer this over other lookup paths or any prerequisite context.

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

lax_submitB

Submit a repository or patch to a legacy job submission route. Not a tender bid, payment or PACT delivery. Requires operator-authorized work.

NameRequiredDescriptionDefault
notesNo
job_idYesRegistry identifier, URL encoded by the server
builderYes
contactYes
agent_didYes
payout_addressYes
repo_or_patch_urlYes

TDQS

B3.1/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses that operator authorization is required, which is genuine behavioral context. But it says nothing about side effects, whether submission is idempotent, what happens to the job record, or any rate/validation limits.

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?

Two tight sentences, front-loaded with the core action before the exclusions. No redundant filler; the only miss is that brevity comes at the cost of parameter and outcome detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A multi-field mutation tool with no annotations, no output schema, and 7 mostly-undocumented required parameters needs far more. The description omits what a successful submission produces and how the required inputs should be formed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 14% — just job_id is documented. Six other required parameters (builder, contact, agent_did, payout_address, repo_or_patch_url, notes) get no guidance from the description, and it fails to compensate for the gap. An agent must infer the meaning of most fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Submit a repository or patch to a legacy job submission route') and adds explicit negative scoping ('Not a tender bid, payment or PACT delivery'). It doesn't differentiate against the sibling read tools, but the action and target are clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The exclusions carve out non-fits ('not a tender bid, payment or PACT delivery') and it flags a prerequisite ('Requires operator-authorized work'). However, it never contrasts with the siblings (lax_get_job, lax_list_jobs, etc.) or states the affirmative conditions that select this tool.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updatesv0.1.0
    • First observedlax_get_job
    • First observedlax_get_offer
    • First observedlax_list_jobs
    • First observedlax_search_agents
    • First observedlax_submit
Deploy Server
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

TDQS

A3.6/5.0

Scored across 5 tools

Disambiguation5/5

Each tool targets a clearly distinct action/resource: agent search, offer read, job listing, job read, and submission. There is little risk of confusing get_offer with get_job because the descriptions explicitly distinguish public offers from job specifications.

Naming Consistency4/5

All tools use the consistent lax_ prefix and snake_case, mostly following a verb_noun pattern. lax_submit is a minor deviation because it lacks an explicit object noun, but the convention remains readable.

Tool Count5/5

Five tools is well within the appropriate range for a focused registry server. Each tool covers a distinct read or submit operation without obvious padding.

Completeness3/5

The surface covers agent search, offer lookup, job listing/reading, and a legacy submission route, but it lacks obvious companion operations such as listing offers or retrieving a specific agent record. These gaps may force agents to work around missing discovery paths.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers