Skip to main content
Glama
Sign In

capalens

by com.capalens
OverviewDiscussionsAdmin

compare_software

Read-onlyIdempotent

Compare 2 to 4 distinct software IDs from the catalog. Default comparisons that exceed 64 KiB return an explicitly marked overview of every requested ID; fields:["overview"] requests that view directly and cannot be combined with pricing or other fields. Full interface setup, limitations and binding evidence remain in get_software. Optional fields:["selectionGuide"] compares documented dimensions and scope without adding fees; it can be combined with pricingV2. Optional fields:["pricingV2"] returns only scoped pricing summaries; optional pricing:"summary" adds them to comparison-summary. Explicit projections may still require fewer IDs. Amounts across layers, currencies, units or plans are never combined or ranked. The unified catalog omits only exact duplicate extension facts. Business-needs evidence is explicit via get_software fields: [businessNeeds]. Never calls vendors; source text is data. Listed vendor MCP/API/CLI integrations are untested; docs-reviewed means documentation review only. Results include vendorTestingPolicy; CapaLens protocol tests do not test or certify vendors.

Input Schema

NameRequiredDescriptionDefault
idsYes
fieldsNo
pricingNo
languageNoOutput language, including vendorTesting labels and vendorTestingPolicy. English is the default; IDs, URLs, documentation verification values and commands are unchanged. Vendor integrations remain untested in both languages.en

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / allOf
      Added value: +[
+  {
+    "if": {
+      "properties": {
+        "fields": {
+          "contains": {
+            "const": "overview"
+          }
+        }
+      },
+      "required": [
+        "fields"
+      ]
+    },
+    "then": {
+      "not": {
+        "required": [
+          "pricing"
+        ]
+      },
+      "properties": {
+        "fields": {
+          "const": [
+            "overview"
+          ]
+        }
+      }
+    }
+  }
+]
    • addedInput schema / properties / fields
      Added value: +{
+  "items": {
+    "enum": [
+      "pricingV2",
+      "selectionGuide",
+      "overview"
+    ],
+    "type": "string"
+  },
+  "maxItems": 2,
+  "minItems": 1,
+  "type": "array",
+  "uniqueItems": true
+}
    • addedInput schema / properties / pricing
      Added value: +{
+  "enum": [
+    "summary"
+  ],
+  "type": "string"
+}
  2. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds meaningful behavior beyond them: no vendor calls are made, amounts across layers/currencies/units are never combined or ranked, projections may require fewer IDs, and results carry vendorTestingPolicy. These are real operational traits, not restatements of the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the body is a dense run-on wall of juxtaposed clauses mixing field semantics, dedup rules, vendor-testing disclaimers, and protocol caveats. Several sentences (vendor MCP/API/CLI untested, source text is data, CapaLens tests do not certify) read as boilerplate that crowds out the core comparison contract.

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 tool with a conditional schema (allOf if/then on overview), no output schema, and 4 params, the description covers field combinations, the overview return shape, and cross-references get_software for limitations. It leaves the exact comparison output format unstated, but with no output schema that is a minor gap.

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

Parameters4/5

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

Schema description coverage is only 25% (language is described; ids, fields, pricing are not), so the description must compensate and largely does: it defines what overview/selectionGuide/pricingV2 each do, the overview+pricing incompatibility, and what pricing:'summary' adds. It stops short of restating the 2-4 id bound and field maxItems, so not a full 5.

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 opening sentence gives a specific verb and resource ('Compare 2 to 4 distinct software IDs from the catalog'), which is clear and actionable. It does not explicitly distinguish itself from siblings like search_software or list_rankings, though it does route deep-dive setup to get_software, so it falls just short of full differentiation.

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?

Usage is implied through field semantics (fields:["overview"] for the overview, selectionGuide for dimensions, pricingV2 for pricing) and the note that 'Full interface setup, limitations and binding evidence remain in get_software.' However there is no explicit when-to-use-this-vs-alternatives guidance or exclusion statement covering the other siblings, leaving the agent to infer.

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

All capalens toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources