StealthStack ARD Discovery

Get one discovered resource

get_resource

Read-onlyIdempotent

Get the full record for one discovered ARD resource by its identifier (URN), as returned by search_resources / list_resources. Includes the connect URL when the publisher provides one; otherwise the inline connection or pull details. Also returns type, publisher, version, trust, source, description, tags, and example queries.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`identifier`	Yes	The resource URN, e.g. urn:air:stealthstack.ai:skill:parquet (urn:ai: and urn:air: are both accepted).

Output Schema

TableJSON Schema

Name	Required	Description
`found`	Yes
`resource`	No
`resolvedIdentifier`	No	The identifier the index matched (may use the other URN prefix).
`requestedIdentifier`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 7, 2026

addedOutput schema / properties / resource / properties / payment

Added value: +{
+  "description": "Payment terms the service lists (x402): protocol, lowest listed price + currency, network (CAIP-2). Self-declared; never a payee address.",
+  "properties": {
+    "currency": {
+      "type": "string"
+    },
+    "network": {
+      "type": "string"
+    },
+    "price": {
+      "type": "string"
+    },
+    "protocol": {
+      "type": "string"
+    },
+    "testnet": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "protocol"
+  ],
+  "type": "object"
+}

First observedSep 27, 2026

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and non-destructive, so the safety profile is covered. The description adds useful behavior content: it says the record includes the connect URL when provided, or inline connection/pull details otherwise, and that it returns type, publisher, version, trust, source, description, tags, and example queries. It does not mention auth requirements, rate limits, or error behavior for a missing URN.

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 sentences, front-loaded with the primary action and resource, followed by return-content details. No filler. Could be slightly tighter given some returned fields are also implied by the output schema.

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 single-record read tool with full annotation coverage, a 100%-covered one-parameter schema, and an output schema, this description is essentially complete: it specifies the lookup key, the source of that key, and the notable payload content. Missing only minor operational details like auth or not-found handling.

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 documents the single identifier parameter with URN examples and accepted prefixes (urn:ai: and urn:air:). The description refers to the identifier/URN but adds no syntax or format detail beyond the schema, so baseline 3 is appropriate.

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

Purpose5/5

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

The description states a specific verb ('Get') and resource ('the full record for one discovered ARD resource by its identifier (URN)'), and explicitly names the sibling tools that produce the identifier ('as returned by search_resources / list_resources'). This lets an agent distinguish it from the list/search siblings without opening any schema.

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

Usage Guidelines4/5

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

Usage context is clear: it fetches a single record by URN, implying the identifier comes from list_resources or search_resources. It does not give explicit when-not-to-use guidance or state that search should be used for discovery, but the workflow is strongly implied by naming the siblings.

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

All StealthStack ARD Discovery tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?