Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Archimedes Market Catalog MCP Search for funded bug bounties under $300"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A production-ready, read-only Model Context Protocol server for discovering engineering work and reusable assets on Archimedes Market. It gives Claude, Cursor, Copilot-compatible MCP hosts, and other agents four small typed tools:
Tool | Purpose |
| Search public engineering asset titles and summaries |
| Fetch one asset's public metadata and description |
| Search the official no-auth bounty API with filters |
| Fetch requirements, deliverables, and acceptance tests |
The server has no write tools and accepts no user credentials. It reads only Archimedes' public bounty API and the anonymous published-asset catalog used by the Archimedes browser client.
Node.js 20.18.1 or newer
Network access to https://archimedes.market
Related MCP server: @clawket/mcp
npm install
npm run ci
npm startnpm start launches the verified stdio entry point after the TypeScript build.
Add this server to claude_desktop_config.json:
{
"mcpServers": {
"archimedes-catalog": {
"command": "node",
"args": ["C:/path/to/archimedes-market-catalog-mcp/dist/index.js"]
}
}
}Restart Claude Desktop, then try:
Find funded software bounties between $100 and $500. Inspect the most relevant result and summarize its required deliverables.
Create .cursor/mcp.json:
{
"mcpServers": {
"archimedes-catalog": {
"command": "node",
"args": ["C:/path/to/archimedes-market-catalog-mcp/dist/index.js"]
}
}
}The same stdio configuration works in any standards-compatible MCP host.
search_bounties:
{
"query": "MCP",
"category": "software",
"funding_status": "funded",
"min_price_cents": 10000,
"max_price_cents": 50000,
"limit": 10
}get_bounty:
{
"id": "89c2e397-bf5d-47d5-af06-7c5b749d76d1"
}search_assets:
{
"query": "Python",
"limit": 10
}get_asset:
{
"id": "1878153b-096a-486e-ac6b-7197346bdff2"
}MCP host
└─ stdio transport
└─ typed, read-only MCP tools
├─ /api/public/bounties
├─ /api/public/bounties/{id}
└─ published assets (public read-only data service)The current public JSON API exposes bounty search and detail records. The
asset tools use the same anonymous catalog endpoint as the public web
application, always constrain reads to status=published, and return metadata
only. They never download paid files or bypass access controls.
strict UUID, pagination, price-range, and result-size validation;
15-second request timeout;
2 MB response cap;
allowlisted Archimedes API origins and cross-origin request rejection;
no redirects, user authentication, environment secrets, or write methods;
MCP errors contain actionable HTTP/validation context.
npm test
npm run test:liveThe regular suite is deterministic. The opt-in live suite exercises all four tools against published Archimedes records and is intended for release verification.
The included multi-stage Dockerfile builds a non-root runtime image. It can
run as a stdio worker in AWS ECS/Fargate, Azure Container Apps jobs, Google
Cloud Run jobs, or any agent runtime that launches MCP subprocesses. Hosted
MCP gateways can wrap the stdio process with their preferred authenticated
HTTP transport without changing the catalog client.
MIT
Fetch the public metadata and published description for one Archimedes asset.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Archimedes asset UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds that metadata is public and description is published, which is consistent but does not disclose other potential behaviors like authentication requirements or response 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, 10 words, directly states purpose with no filler. Optimal conciseness.
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 explains the return type (public metadata and published description) but lacks detail on what fields are included or error handling. Still sufficient for a simple fetch 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% with a clear description of the id parameter. The tool description does not add additional semantics beyond what the schema provides, so baseline of 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?
Description clearly states the action (fetch), the resource (public metadata and published description for one Archimedes asset), and distinguishes from sibling tools like search_assets (which returns multiple) and get_bounty (which returns a 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?
Description implies use when you have a specific asset ID, but does not explicitly state when not to use or mention alternative tools. The context of siblings is not leveraged for guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one full public bounty record, including requirements, deliverables, and acceptance tests.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Archimedes bounty UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe read operation. The description adds value by specifying what the returned record contains (requirements, deliverables, acceptance tests), which is beyond the annotations. 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?
The description is a single concise sentence that immediately conveys the tool's purpose and output content. No unnecessary words, front-loaded with key information.
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 low complexity (one parameter, no output schema), the description is complete. It explains what the tool fetches (full record with specific components), which is sufficient for an AI agent to understand the return value.
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 the single required 'id' parameter fully described (UUID format, pattern). The description does not add additional parameter meaning or usage hints, 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 verb 'fetch' and resource 'full public bounty record', clearly indicating it retrieves a single bounty by ID. It also lists included content (requirements, deliverables, acceptance tests), distinguishing it from sibling tools like 'search_bounties' which returns multiple results.
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?
While no explicit when-not or alternative naming is present, the description implies usage when a single bounty record is needed by ID. The existence of 'search_bounties' as a sibling provides context, but the description itself doesn't guide the agent on choosing between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Archimedes Market's public engineering asset catalog by title and summary.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return (default 20) | |
| query | No | ||
| offset | No | Zero-based result offset |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations readOnlyHint and openWorldHint already declare safety and variable results. The description adds that the catalog is public and search is by title and summary, but provides no further behavioral details (e.g., pagination, ordering).
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 11 words, no extraneous information, front-loaded with action and resource.
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 does not explain return values or result structure. It covers basic search purpose but lacks details on result format, matching behavior, or edge cases.
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 67% (limit and offset described). The description adds meaning to the query parameter by specifying 'by title and summary', which compensates for the missing schema description of query.
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 searches a public catalog by title and summary, distinguishing it from sibling tools like get_asset (retrieve specific asset) and search_bounties (search bounties).
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 for searching assets but does not explicitly state when to use it versus get_asset or search_bounties, nor does it provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Archimedes' no-auth public bounty API with category, funding, price, and text filters.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return (default 20) | |
| query | No | ||
| offset | No | Zero-based result offset | |
| category | No | ||
| funding_status | No | ||
| max_price_cents | No | ||
| min_price_cents | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds valuable context: it is a 'public bounty API' with 'no-auth', which informs the agent about accessibility and safety. No contradictions 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?
Single sentence, front-loaded with key information. Every word is meaningful; no redundancy or filler.
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 7 parameters and no output schema, the description is brief. It misses return format, pagination details, and ordering. However, annotations partially compensate with openWorldHint. Adequate but has 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?
With only 29% schema coverage, the description must compensate but only provides high-level filter categories. It does not detail individual parameters like min/max_price_cents or default values. The listing of filter types is minimal help.
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 verb 'search', the resource 'bounties', and the API context with filters (category, funding, price, text). It distinguishes from siblings like 'get_bounty' (single bounty) and 'search_assets' (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 mentions 'no-auth public' implying accessibility, but does not provide explicit guidance on when to use this tool versus alternatives (e.g., 'get_bounty' for a specific bounty, 'search_assets' for assets). No when-not-to-use or prerequisites are stated.
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.
v1.0.0get_assetget_bountysearch_assetssearch_bountiesEach tool targets a distinct resource-action pair: assets (search, get) and bounties (search, get). No overlap in purpose; an agent can easily distinguish them.
All tool names follow a consistent verb_noun pattern: search_assets, get_asset, search_bounties, get_bounty. No mixing of conventions or vague verbs.
Four tools is well-scoped for a read-only catalog server covering two entity types. Each tool serves a clear purpose without being too few or too many.
The server provides search and retrieval for both assets and bounties, covering basic discovery needs. Potential gaps like listing all assets or bounties are accommodated by search, but no create/update operations exist, which is acceptable for a read-only catalog.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
Read-only MCP tools for AI agent discovery, structured resources, and NIULAI information.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nexicturbo/archimedes-market-catalog-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
