mcp-archimedes

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

No annotations exist, so the description carries full burden. It transparently explains the 'not_scanned' status and clarifies it means unexamined, not unsafe. It also mentions the max 30 entries limit. While it doesn't disclose auth or rate limits, the read-only nature is implied.

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 concise, well-structured, and front-loaded. Each sentence serves a purpose: stating purpose, input format, output, usage guidance, and clarification of edge case. No superfluous content.

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 lacking an output schema, the description adequately explains the return values (scores, badge, link) and handles the 'not_scanned' edge case. With only one parameter and simple input, the description is complete for effective tool selection and invocation.

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 for the 'packages' parameter. The description adds value by specifying the allowed string formats (npm package names and GitHub coordinates) and reinforcing the max 30 constraint, which goes 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?

The description clearly states it performs a supply-chain trust check for dependencies, specifies the input types (npm packages or GitHub coordinates), and describes the output (scores, badge, link). This differentiates it from sibling tools like check_repo_trust which likely handles single repositories.

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?

Explicit usage guidance is given: 'CALL THIS BEFORE INSTALLING PACKAGES' and lists concrete scenarios (reviewing package.json, lockfile, recommending library). It also explains the 'not_scanned' status and when to warn. While no explicit when-not-to-use is stated, the guidance is strong.

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

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

No annotations provided, so description carries full burden. It discloses that the tool returns scores, badges, findings, and license SPDX, and handles the 'not_scanned' case with a scan URL. It implies the repo must be public. Missing details like authentication or rate limits, but still informative.

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: first describes output thoroughly, second states usage. No wasted words, front-loaded with purpose and details.

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, description fully explains return values and special cases (not_scanned). Covers interpretation of absence of report. Sufficient for an agent to understand expected results.

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 well-described parameters (repo and owner). Description adds minimal extra meaning beyond using the tool for trust evaluation, which is appropriate given schema completeness.

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 produces a 'Full Archimedes Trust Report' for one public GitHub repository, listing specific scores and details. It distinguishes from siblings like check_dependencies and search_trust_reports by focusing on a single repo's trustworthiness assessment.

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?

Explicitly says 'Use when the user asks whether a specific repo or tool is trustworthy, safe to depend on, or well maintained.' Provides context for when to invoke, and clarifies that absence of a report is not evidence of a problem. No explicit exclusion of alternatives, but clear enough.

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

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

No annotations provided, so description carries full burden. It describes what the tool returns but does not disclose behavioral traits like idempotency, side effects (none expected), authentication requirements, or rate limits. The name implies read-only, but this is not explicitly stated.

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 efficient sentences: first defines purpose, second gives usage context and return value highlights. 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 no output schema, the description adequately lists the categories of returned data. It also fits well with sibling tool search_bounties. Could mention ordering or pagination if applicable, but those likely don't apply here.

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 id parameter has a detailed description explaining it requires the UUID from search_bounties (not display ID), which adds significant value beyond the schema's basic format and required tag. Schema coverage is 100%, but the description goes further.

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 fetches the full record for a specific bounty, and distinguishes it from search_bounties by listing additional fields returned (description, requirements, deliverables, acceptance tests). The verb 'Fetch' and resource 'bounty' are specific.

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?

Explicitly states 'Use this after search_bounties' and gives three concrete scenarios (evaluate fit, plan submission, quote timeline). Could be improved by explicitly mentioning when not to use (e.g., if only metadata is needed).

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

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

No annotations provided, so description carries full burden. It discloses that counters are cached upstream with a 60-second TTL, which is important for behavior understanding. It does not explicitly mention read-only nature or authentication needs, but that is implied by the purpose.

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: first defines the tool's output, second lists use cases. No filler, front-loaded, every sentence earns its place.

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 no-parameter stat retrieval tool, the description fully informs the agent of the returned data and appropriate contexts. No output schema exists, but the explicit list of counters provides sufficient clarity.

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 exist, baseline is 4. Description adds value by explaining the output content, compensating for lack of parameter details.

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 aggregate counters for the Archimedes Market platform, listing specific metrics (published assets, funded bounties, verified engineers, total USD paid out). This distinctively separates it from sibling tools which focus on bounties, dependencies, or trust reports.

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 explicitly provides use cases: evaluating platform worth, sizing talent pool, surfacing momentum. This gives clear guidance on when to use this tool, and the sibling tools list implies alternatives for other tasks.

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

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

With no annotations provided, the description carries full burden. It discloses that results are paginated and lists returned fields (title, summary, payout, deadline, URL). However, it lacks details on pagination behavior (e.g., max pages), rate limits, or any side effects.

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 a bulleted usefulness list. It is front-loaded with the core action and result, and every 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?

Given the tool has 7 parameters and no output schema, the description adequately covers what the tool returns and its filtering capabilities. It could mention the output format more explicitly, but overall it is sufficient for an agent to use.

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 the baseline is 3. The description adds high-level grouping of filters ('free-text query, mission category, funding status, price band') but does not provide extra meaning beyond the schema's own 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 uses a specific verb ('Search') and resource ('open bounties on Archimedes Market'), clearly stating what the tool does. It distinguishes from siblings like 'get_bounty_details' by focusing on list/search functionality.

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 provides use cases ('agents discovering paid engineering work, users browsing bounties via an AI assistant, dashboards aggregating...'), guiding when to use. It implicitly excludes individual bounty lookup, but does not explicitly contrast with siblings.

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

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

With no annotations, the description adequately discloses behavioral traits: it returns repos sorted by score, including scores, badge, and report URL. It does not mention destructive effects, which is appropriate for a search 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?

The description is three sentences, front-loading the main action, followed by filters and use cases. Every sentence adds value without redundancy.

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 complexity (4 parameters, no output schema, no annotations), the description covers purpose, filters, example intents, and output summary. It lacks pagination or error details, but is sufficient 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 75%, so the baseline is 3. The description adds value by explaining the filtering logic ('Filter by keyword, asset class, and/or minimum overall score') and the sorting behavior ('best-scoring first'), which are not fully captured in 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?

The description uses a specific verb ('Search') and clearly identifies the resource ('Archimedes corpus of scored public repositories'), and distinguishes from sibling tools like search_bounties by specifying the corpus and output.

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 provides clear usage context with example user queries ('what are the most trustworthy MCP servers') and use cases ('compare candidates before recommending one'), but does not explicitly state when not to use this tool or name alternatives.

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