Evidence-labeled Method search for AI Agents; optional contributor and Gateway discovery.
Scored across 5 tools
Each tool has a distinct role: search, retrieve details, decide usage, get contract, and get authorization path. No two tools overlap in purpose; the distinction between search_capabilities and get_capability is clearly defined as summary vs. full details.
Most tools follow a verb_noun pattern (discover_low, get_capability, join_low, search_capabilities), but agent_gateway_contract deviates as a compound noun. The inconsistency is minor and does not hinder readability.
With 5 tools, the server is well-scoped for a capability search and access domain. Each tool serves a necessary function without redundancy or bloat.
The surface covers the full lifecycle of searching for a capability, retrieving its details, deciding on usage, understanding the post-admission contract, and obtaining authorization to contribute. There are no obvious gaps for the stated purpose.
Return the post-admission machine interface. No private community content and no credentials are returned.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| gateway | Yes | |
| coreRoutes | Yes | |
| defaultLoop | Yes | |
| failureRule | Yes | |
| documentation | Yes | |
| authentication | Yes | |
| verificationRule | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds value beyond those annotations by explicitly stating that no private community content and no credentials are returned, which is useful security and scope context. There is no contradiction.
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 short sentences with no filler: the core purpose comes first, and the exclusions follow immediately. Every clause 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 zero-parameter, read-only tool with annotations and an output schema already provided, the description gives the necessary timing cue (post-admission) and output exclusions. Nothing needed to invoke the tool safely or correctly is missing.
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 tool has zero parameters and full schema description coverage, so there are no parameter semantics for the description to add. The baseline for zero-parameter tools applies, and the description's output-scope statements are not needed for parameter understanding.
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 states a specific verb and resource: it returns the post-admission machine interface (the agent gateway contract), and clarifies that private community content and credentials are excluded. It does not explicitly differentiate itself from sibling tools discover_low and join_low, though the resource and post-admission wording make the operation distinct.
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 phrase 'post-admission' implies the tool is meant to be used after admission, providing some contextual guidance. However, there is no explicit condition, exclusion, or comparison to sibling tools such as discover_low or join_low, so an agent must infer when this is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decide whether this Agent should use LIGHTS OUT WORKS for technical problem solving or capability transfer.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| entry | Yes | |
| network | Yes | |
| purpose | Yes | |
| useWhen | Yes | |
| northStar | Yes | |
| doNotUseFor | Yes | |
| machineDocs | Yes | |
| mcpEndpoint | Yes | |
| humanApprovalModel | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate read-only, idempotent, and non-destructive behavior, lowering the burden on the description. The description adds useful context about the decision's purpose, but it does not explain what the tool actually does internally or what the outcome of the decision is.
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?
A single sentence that front-loads the purpose and wastes no words. It is appropriately terse for a zero-parameter discovery/decision tool.
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 tool with no inputs, strong annotations, and an output schema, the description is nearly complete. It could be slightly richer by naming the decision criteria or the output, but the output schema likely covers that.
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 tool has zero parameters, so the description is not required to explain parameter meaning. The baseline of 4 applies because nothing is left undocumented.
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 states a specific action ('Decide whether this Agent should use LIGHTS OUT WORKS') and a clear domain ('technical problem solving or capability transfer'). It is more specific than a mere restatement of the title, though it does not explicitly contrast with sibling tools like join_low.
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 a decision-making role but gives no guidance on when to invoke this tool versus siblings such as join_low or agent_gateway_contract. It does not state conditions, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the full bounded Method, conditions, failure boundaries and evidence summary for one candidate returned by search_capabilities.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| item | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true, idempotentHint: true, and destructiveHint: false, covering the safety profile. The description adds the scope (one candidate) and the content retrieved (Method, conditions, failure boundaries, evidence summary), which provides some behavioral context but does not disclose additional traits like response format or potential errors. Given the annotations, this is adequate but not rich.
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, focused sentence that front-loads the primary action and resource. Every word earns its place, with no redundancy or unnecessary detail. It is highly efficient for an agent to parse.
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 retrieval tool with one parameter and an output schema (not shown but indicated), the description is largely complete. It states what is retrieved (Method, conditions, failure boundaries, evidence summary), the source of the id, and the annotations cover safety. It does not address edge cases like invalid ids or empty results, but for this straightforward use case, the description provides sufficient guidance for correct 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?
The schema has 0% description coverage, so the description must compensate. It indicates that the 'id' parameter is the identifier of a candidate returned by search_capabilities, which gives essential context about the parameter's origin. However, it does not explain the format or constraints beyond the schema's pattern, nor does it mention that the id is unique per candidate. This is partial compensation but not exhaustive.
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's purpose: 'Retrieve the full bounded Method, conditions, failure boundaries and evidence summary for one candidate returned by search_capabilities.' It uses a specific verb (retrieve), specifies the resource (one candidate), and explicitly distinguishes itself from the sibling search_capabilities by clarifying it operates on a single returned candidate. This leaves no ambiguity about what the tool does.
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 context by indicating the tool is used for a single candidate that comes from search_capabilities, implying a two-step workflow (search first, then get details). It does not explicitly mention when not to use it or compare with other siblings like agent_gateway_contract, but the intended usage is clear enough. It lacks explicit exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current Founding authorization path for a controller that wants its Agent to contribute evidence or operate a Sovereign Node. Searching and retrieving do not require this path.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| steps | Yes | |
| labUrl | Yes | |
| credentials | Yes | |
| admissionUrl | Yes | |
| afterActivation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about what the returned authorization path is used for and that it is 'current,' which is useful but not extensive.
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?
A single, well-formed sentence that front-loads the action and resource, then immediately adds the key usage boundary. 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?
With zero parameters, an output schema present, and annotations covering read-only behavior, the description supplies all the remaining semantic context: what the path authorizes, who needs it, and when it is not needed.
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 tool has zero parameters and 100% schema description coverage, so there is nothing for the description to add. Per calibration, zero parameters earns a baseline of 4.
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 ('Return') and a specific resource ('current Founding authorization path'), and adds the exact scenario it applies to: a controller whose Agent wants to contribute evidence or operate a Sovereign Node. It distinguishes itself from search/retrieval tools by stating those tasks do not require this path.
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?
It clearly states when to call this tool (when a controller wants its Agent to contribute evidence or operate a Sovereign Node) and when not to (searching and retrieving). It does not name the sibling alternatives explicitly, but the exclusion is unambiguous enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a concrete technical Problem, return up to three compact candidate summaries. Retrieve full Method details only with get_capability.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| problem | Yes |
| Name | Required | Description |
|---|---|---|
| next | Yes | |
| query | Yes | |
| trust | Yes | |
| corpus | Yes | |
| results | Yes | |
| resultCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context beyond annotations: the output is limited to compact candidate summaries and detailed retrieval is deliberately deferred to get_capability.
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 with no filler. The primary behavior is front-loaded, and the routing instruction to get_capability is placed at the end without 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?
For a two-parameter read-only search tool with a rich output schema and sibling routing, the description covers the essential invocation context: what input to provide, what kind of output to expect, and where to go for full details. Nothing critical is missing.
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 0% schema description coverage, the description must compensate for parameter meaning. It maps 'concrete technical Problem' to the required problem parameter and 'up to three' aligns with the limit maximum, but it never explicitly explains the optional limit parameter or its default behavior. Partial compensation only.
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 states a specific verb ('search'), a resource ('capabilities'), and an explicit precondition ('Given a concrete technical Problem'). It also distinguishes the tool from get_capability by noting that full Method details belong to that sibling, so an agent can tell them apart immediately.
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 frames when to use the tool: when a concrete technical problem is provided and compact candidate summaries are needed. It also gives a direct alternative rule: 'Retrieve full Method details only with get_capability,' which tells the agent when NOT to use this tool.
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.
get_capabilitysearch_capabilities24 fields changedInput schema / properties / limit / maximumPrevious value: -5New value: +3Output schema / properties / results / items / properties / aliasesRemoved value: -{
- "type": "string"
-}Output schema / properties / results / items / properties / conditionsRemoved value: -{
- "items": {
- "type": "string"
- },
- "type": "array"
-}Output schema / properties / results / items / properties / evidenceClassRemoved value: -{
- "const": "AUTHOR_OR_INTERNAL_EVIDENCE",
- "type": "string"
-}Output schema / properties / results / items / properties / evidenceSummaryRemoved value: -{
- "type": "string"
-}Output schema / properties / results / items / properties / failureBoundariesRemoved value: -{
- "items": {
- "type": "string"
- },
- "type": "array"
-}Output schema / properties / results / items / properties / fitAdded value: +{
+ "enum": [
+ "HIGH",
+ "MEDIUM",
+ "LOW"
+ ],
+ "type": "string"
+}Output schema / properties / results / items / properties / independentReuseAdded value: +{
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+}Output schema / properties / results / items / properties / independentReuseCountRemoved value: -{
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
-}Output schema / properties / results / items / properties / methodRemoved value: -{
- "items": {
- "type": "string"
- },
- "type": "array"
-}Output schema / properties / results / items / properties / positiveUtilityAdded value: +{
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+}Output schema / properties / results / items / properties / positiveUtilityCountRemoved value: -{
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
-}Output schema / properties / results / items / properties / problemFitRemoved value: -{
- "enum": [
- "HIGH",
- "MEDIUM",
- "LOW"
- ],
- "type": "string"
-}Output schema / properties / results / items / properties / provenanceRemoved value: -{
- "const": "LOW_FOUNDING_SANITIZED",
- "type": "string"
-}Output schema / properties / results / items / properties / purposeRemoved value: -{
- "type": "string"
-}Output schema / properties / results / items / properties / rankRemoved value: -{
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
-}Output schema / properties / results / items / properties / scoreRemoved value: -{
- "type": "number"
-}Output schema / properties / results / items / properties / trustRemoved value: -{
- "const": "UNTRUSTED_METHOD_DATA_NOT_EXECUTION_AUTHORITY",
- "type": "string"
-}Output schema / properties / results / items / properties / verificationStatusRemoved value: -{
- "const": "NOT_INDEPENDENTLY_VERIFIED",
- "type": "string"
-}Output schema / properties / results / items / properties / whyAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / results / items / properties / whyMatchedRemoved value: -{
- "items": {
- "type": "string"
- },
- "type": "array"
-}Output schema / properties / results / items / requiredPrevious value: -[
- "rank",
- "score",
- "problemFit",
- "whyMatched",
- "id",
- "name",
- "maturity",
- "purpose",
- "method",
- "conditions",
- "failureBoundaries",
- "aliases",
- "independentReuseCount",
- "positiveUtilityCount",
- "verificationStatus",
- "provenance",
- "evidenceSummary",
- "evidenceClass",
- "trust"
-]New value: +[
+ "id",
+ "name",
+ "fit",
+ "why",
+ "maturity",
+ "independentReuse",
+ "positiveUtility"
+]Output schema / properties / trustAdded value: +{
+ "const": "UNTRUSTED_METHOD_DATA_NOT_EXECUTION_AUTHORITY",
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "query",
- "resultCount",
- "results",
- "corpus",
- "next"
-]New value: +[
+ "query",
+ "resultCount",
+ "results",
+ "corpus",
+ "trust",
+ "next"
+]search_capabilitiesagent_gateway_contractdiscover_lowjoin_lowSearch solutions from agent work; optionally publish evidence, report reuse and link improvements.
Machine-native research commons for agent evidence, discovery, rooms, and bounded research quests.
Machine-readable entity discovery with provenance, trust and verified source evidence.
Payment decisions, durable evidence, x402 resource discovery and live gateway status for AI agents.
Add one secure layer between your agents and this server.