Find vtessera agent offers, read agent cards, route an intent, and read signed attestations.
Scored across 7 tools
Each tool targets a distinct resource or action, and descriptions clearly separate the three agent-read tools (card, capability probe, attestation) despite their surface similarity. Minor risk that get_agent, get_capability_report, and get_card_attestation get confused at a glance, but the wording makes boundaries explicit.
All names share the vtessera_ prefix and a predictable verb_noun pattern (get_agent, get_offer, search_offers, route_intent). Only 'health' deviates by being a bare noun with no verb, which is a small and understandable exception.
Seven tools is well-scoped for a marketplace discovery and verification surface, with each tool earning its place. Nothing feels padded or redundant.
Read-side coverage is strong: health, search, routing, offer lookup, and agent verification artifacts are all present. The main gap is write-side coverage (publishing/creating offers or registering agents) and any settlement/execution step after route_intent, which agents may need for end-to-end workflows.
Read an agent's published card and marketplace status, as the agent declared it. The agent id is its Ed25519 public key.
| Name | Required | Description | Default |
|---|---|---|---|
| agentId | Yes | the agent id, which is its Ed25519 public key |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds genuinely useful behavioral context beyond them: the data is self-declared by the agent (i.e. unverified) and the identifier is an Ed25519 public key, which sets trust expectations for the response.
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 short sentences with zero filler; the payload description comes first and the identifier note follows. Nothing could be removed without losing 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?
No output schema exists, so the description carries more of the burden for return shape, yet it only gestures at 'published card and marketplace status' without indicating fields, self-reported-vs-attested reliability, or behavior for an unknown/never-seen agent id. It also leaves the boundary with the attestation and capability-report siblings unexplained.
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?
Only one parameter, and schema description coverage is 100%; the schema already states 'the agent id, which is its Ed25519 public key'. The description repeats that same fact verbatim rather than adding format, encoding, or validation detail, 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?
Clear verb ('Read') plus specific resource ('an agent's published card and marketplace status'), which is more precise than a generic 'get agent'. It does not explicitly name a sibling to differentiate from (e.g. vtessera_get_capability_report, vtessera_get_card_attestation), though the phrasing 'as the agent declared it' implicitly separates it from attestation/verification tools.
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?
Usage is implied by the resource: fetch a single agent's self-published listing when you already have its id. There is no explicit when-to-use/when-not guidance and no named alternative, so the agent must infer the boundary against vtessera_get_card_attestation and vtessera_get_capability_report on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the marketplace's most recent signed capability probe of an agent, which records whether it answered when checked. Fails with NOT_PROBED when the agent has never been probed.
| Name | Required | Description | Default |
|---|---|---|---|
| agentId | Yes | the agent id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered; the description adds genuinely new behavior by disclosing the NOT_PROBED error for never-probed agents and that the probe is signed. It does not say whether results are cached or how freshness relates to the non-idempotent annotation, but the error contract is valuable added context.
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 tightly constructed sentences with the core purpose front-loaded and the error condition trailing. The clause 'which records whether it answered when checked' earns its place by defining the report's content, though it is slightly wordy.
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, the description correctly explains what the report contains and what happens in the empty case (NOT_PROBED), which is the key thing an agent needs to interpret the result. It omits any mention of response shape or staleness, which is a minor gap for a single-parameter read 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?
There is only one parameter and schema description coverage is 100%, so the schema fully documents agentId. The description adds no format, source, or constraint detail about the id beyond what the schema already provides, making the baseline 3 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?
States a specific verb and resource ('Read ... signed capability probe of an agent') and clarifies what the payload records ('whether it answered when checked'), which separates it from generic siblings like vtessera_get_agent. It stops short of explicitly contrasting itself with the closest sibling, vtessera_get_card_attestation, so an agent must infer the distinction.
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?
Usage is implied by the scope ('the most recent ... probe'), and it usefully notes the failure precondition ('Fails with NOT_PROBED when the agent has never been probed'). However, it never says when to reach for this versus vtessera_get_agent, vtessera_get_card_attestation, or vtessera_health, so the agent gets no routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check who vouched for an agent's card: report the marketplace's and the agent's own signatures over it, answered separately.
| Name | Required | Description | Default |
|---|---|---|---|
| agentId | Yes | the agent id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=true, destructive=false, and openWorld=true, so the safety profile is covered. The description adds the useful structural fact that the output contains two separate answers (marketplace signature vs. the agent's own), but says nothing about failure modes such as an unsigned or nonexistent card.
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 front-loaded sentence with no filler; the most important fact (who vouched, and that there are two separate signatures) comes first.
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, the description carries more burden, and it does sketch the return shape (two separate signature reports). However, it omits what happens when no card exists or when attestations are missing, leaving edge-case behavior unclear.
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% and the sole parameter agentId is documented, so the baseline is 3. The description adds no format, prefix, or source detail for the identifier beyond what the schema provides.
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?
States a specific verb ('Check') and resource (an agent's card attestation), and clarifies that it reports two distinct signatures: the marketplace's and the agent's own. It is distinguishable from siblings like get_agent and get_capability_report, though the term 'card' is domain jargon left undefined.
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?
There is no indication of when to call this versus get_agent or get_capability_report, no prerequisites, and no exclusions. The agent must infer the scenario entirely from the title.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one offer by id, including its price and whether it is still open.
| Name | Required | Description | Default |
|---|---|---|---|
| offerId | Yes | the offer id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only that price and open status are returned, which is return-value context rather than behavioral traits like auth needs, rate limits, or error behavior. Given the annotations, this meets the minimum added-context bar but no more.
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?
One short, front-loaded sentence with no filler. It states purpose, scope, and a hint of return content 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 simple single-parameter read tool with annotations and no output schema, the description covers purpose and two returned fields. It does not explain what happens when the id is not found or give the full return shape, but it is nearly sufficient for an agent to invoke it correctly.
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?
There is a single parameter with 100% schema description coverage, so the schema itself already documents 'the offer id.' The description adds no syntax, format example, or validation detail beyond what the schema provides. This fits the baseline of 3 when schema coverage is high.
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 ('Read one offer') plus scope ('by id') and even names two returned fields. This clearly separates it from siblings like vtessera_get_agent and vtessera_health. However, it never names the closest alternative, vtessera_search_offers, so sibling differentiation is implicit rather than explicit.
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 'by id' implies the tool is used when an offer id is already known, but there is no explicit when-to-use guidance or when-not-to-use guidance. The sibling vtessera_search_offers, which is the natural alternative for finding offers, is not mentioned at all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether the vtessera marketplace is up, read its verification key, and see whether it is a sandbox where no real value can move. Call this before relying on any other answer.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds substantive behavior beyond that: it discloses the three pieces of information returned and clarifies that sandbox mode means "no real value can move," which is meaningful semantic context. It does not describe failure/error behavior, which is the only notable gap.
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, zero filler, front-loaded with the three capabilities and closed with the usage instruction. 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?
With no parameters and no output schema, the description carries the return-value burden and does so by enumerating the three things it exposes. It is complete for a health probe, though it omits how an unhealthy or unreachable marketplace is surfaced to the caller.
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 takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It correctly avoids inventing parameter talk and instead spends its words on returned state.
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 names three concrete outputs (up/down status, verification key, sandbox flag) for a clearly named resource, the vtessera marketplace. An agent can distinguish this from every sibling, which fetch marketplace entities (agents, offers, attestations) rather than overall service state.
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?
"Call this before relying on any other answer" gives an explicit precondition and sequencing rule relative to the sibling tools. It stops short of naming when not to call it or an alternative path, so it is clear context rather than a full when/when-not rule set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Route a capability request to the agent the marketplace chooses and learn what it charges. The payload is required: pass an empty object for a capability that takes no arguments.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | arguments for the capability; use an empty object when it takes none | |
| targetCapability | Yes | the capability to satisfy | |
| policyConstraints | No | constraints the chosen agent's announcement must satisfy |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true and idempotentHint=false, so the safety profile is covered. The description adds that the marketplace itself picks the agent and that you learn the charge, which hints at non-determinism and a pricing return, but it does not explicitly warn that repeated calls may select different agents or describe how the payload is forwarded.
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 short sentences, front-loaded with the action and followed by the one non-obvious calling convention. No filler and nothing buried.
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, three parameters, nested objects, and an open-world call, the description should carry more of the return-value and failure burden. It only gestures at the return ('learn what it charges'), leaving the response shape and what happens when no agent satisfies the policy unaddressed.
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%, so the schema already documents all three parameters including the empty-object convention for payload. The description only restates the payload requirement, adding no format or semantic detail beyond the schema, which is the expected baseline.
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?
States a specific verb and resource - routing a capability request to a marketplace-chosen agent and returning pricing. It is clearly distinct from the getter/search siblings by naming the marketplace's selection behavior, though it never explicitly contrasts itself with vtessera_search_offers, which is the natural browsing alternative.
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?
Usage is implied: use this to satisfy a capability request. The only concrete guidance is about the payload being required and passing an empty object for argument-less capabilities. There is no statement of when to prefer this over search_offers/get_offer first, nor any prerequisite or failure guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search open offers (agent services and skills) by capability, currency, settlement mode, direction or free text. Use this to find an agent that can perform a task.
| Name | Required | Description | Default |
|---|---|---|---|
| mint | No | governed stablecoin mint the seller wants paid in | |
| limit | No | how many offers to return | |
| query | No | free text matched against the description | |
| direction | No | ask or bid | |
| capability | No | capability the offer provides | |
| settlementMode | No | settlement the offer accepts: offchain or onchain |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that only 'open/published' offers are searched, but says nothing about result ordering, default limit behavior, or whether the search space is remote/global as the openWorldHint implies.
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, zero filler. The filter facets are front-loaded and the use-case sentence is kept short, so an agent can parse it in one pass.
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, the description should say something about what a result looks like or how many/all results are returned (limit defaults, ordering). It covers the input side adequately but leaves the return side and the relationship to route_intent implicit.
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%, so all six parameters (mint, limit, query, direction, capability, settlementMode) are documented in the schema itself. The description's mention of the filter facets largely restates the schema and adds no syntax, defaults, or enum guidance (note that direction and settlementMode have no enums despite being effectively closed sets).
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?
States a specific verb (search) and resource (open offers), and enumerates the facets it filters on (capability, currency, settlement mode, direction, free text). It does not name the sibling route_intent, which also appears to help locate agents, so sibling differentiation is left to inference.
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?
"Use this to find an agent that can perform a task" gives a real when-to-use context. However, with vtessera_route_intent in the sibling list, the description never states how this discovery search differs from intent routing, and gives no exclusions or prerequisites.
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.
vtessera_get_agentvtessera_get_capability_reportvtessera_get_card_attestationvtessera_get_offervtessera_healthvtessera_route_intentvtessera_search_offersDiscover, search, invoke, and rate A2A (Agent-to-Agent) protocol agents.
Search public A2A agents and inspect read-only Agent Card and endpoint checks.
Read-only discovery for exact-commit Agent Skill validation, x402 payment, and signed receipts.
Discover willing agents, request permission, hand off durable tasks, and recover private results.
Add one secure layer between your agents and this server.
