Query a company's Bifrost trust gateway: cited answers and approved actions with signed receipts.
Scored across 4 tools
Each tool maps to a distinct stage of the lifecycle: discovery (find_company), structured read (get_trust_profile), free-form Q&A (ask_company), and demand capture (invite_company). The only real overlap is that ask_company can answer questions that get_trust_profile already returns structurally (frameworks, subprocessors), but the descriptions distinguish prose answers from structured reads well enough.
All four tools follow a clean verb_object snake_case pattern: ask_company, find_company, get_trust_profile, invite_company. The only variation is a compound object (trust_profile), which still fits the same convention and reads predictably.
Four tools is slightly lean but each earns its place and covers a distinct verb (find, get, ask, invite) with no filler. It sits at the low edge of the ideal 3-15 range rather than being badly scoped.
The surface covers discovery, profile reading, Q&A, and onboarding interest, and ask_company provides a workaround path to evidence beyond structured fields. The clear gap is that documents are only returned as titles with no way to fetch their contents, and there is no way to list or browse companies beyond a direct name/domain lookup.
Ask a listed company a question. The answer comes only from its public-tier evidence with exact source citations and a signed receipt, or a refusal when public evidence does not support an answer.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | ||
| question | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond the annotations by disclosing the evidence tier (public only), that answers carry exact source citations and a signed receipt, and that the tool can refuse when evidence is insufficient. This is meaningful behavioral context an agent cannot get from readOnlyHint=false or openWorldHint=false. It does not address cost, latency, or rate limits.
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 tight sentences, front-loaded with the action and followed by the key behavioral guarantees. No filler and nothing repeated from structured fields.
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 does some work by describing the answer shape (cited, signed receipt) and the refusal case, which is the right priority. However, it omits the company identifier format and any indication of what a refusal response looks like or what the caller should do next, leaving real gaps for a two-parameter tool with zero schema coverage.
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 0%, so the description must carry parameter meaning and does not. It never says whether 'company' is a name, ticker, domain, or ID accepted by find_company, nor does it explain the question format or why questions are capped at 1000 characters.
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: ask a listed company a question, and characterizes the answer as evidence-backed with citations. It does not explicitly distinguish itself from siblings like find_company or get_trust_profile, but the verb 'ask' makes the intent clear enough.
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?
No guidance on when to use this versus find_company or get_trust_profile, and no prerequisites stated. It is unclear whether the company must first be resolved via find_company, or when the caller should expect a refusal rather than attempting the call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a company's public trust center by name or domain. A match whose domain is domain-verified is proven to belong to the company; a name match without a verified domain is self-asserted by the workspace owner — say so when you rely on it.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/non-destructive/closed-world, so the safety profile is covered; the description adds genuinely extra behavioral context about result trust — domain-verified matches are proven, name-only matches are self-asserted — and tells the agent to surface that distinction. It omits what happens on no match or multiple matches.
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, front-loaded with the action and lookup keys, followed by the trust caveat that materially affects how the result should be reported. Dense and mostly waste-free, though the second sentence is long.
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 single-parameter, annotated read tool with no output schema, the description covers what is found and how far the result can be trusted — the critical decision input. Missing only edge-case behavior (no result, multiple candidates).
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 carry the parameter burden; it partially does by stating the query accepts a name or a domain. It does not clarify matching behavior, case sensitivity, or how ambiguous/partial queries are resolved, so the lone parameter remains only half-documented.
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 gives a specific verb and resource ('Find a company's public trust center') and names the lookup keys ('by name or domain'), so the agent knows exactly what this returns. It does not explicitly contrast itself with siblings like get_trust_profile or ask_company, leaving the boundary to be inferred.
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 lookup framing (use this when you need to locate a company by name or domain), but there is no explicit when-to-use versus ask_company/invite_company/get_trust_profile routing and no stated preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the public-tier trust profile a listed company publishes: its summary, framework and control statuses, subprocessors and the titles of its public documents. Never returns private or restricted material.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: results are limited to publisher-disclosed public material and private/restricted data is never returned. It does not cover auth needs or what happens for an unknown/unlisted company.
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 dense sentences, front-loaded with the action and scope, then the returned contents, then the privacy boundary. No 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?
There is no output schema, and the description compensates well by listing the profile's sections. The remaining shortfall is caller-side: nothing tells the agent how to form the `company` identifier or how to handle an unlisted company.
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 single `company` parameter has 0% schema description coverage, and the description only says 'a listed company' without specifying whether the value is a name, ticker, domain, or an ID obtained from find_company. With one required param and no schema help, this is the definition's biggest gap.
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 (Read) and resource (trust profile), and enumerates exactly what the profile contains: summary, framework and control statuses, subprocessors, and document titles. The 'public-tier ... a listed company publishes' scoping makes it unmistakable versus ask_company, find_company, and invite_company.
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 content list (use when you need a company's published trust/compliance posture), and 'Never returns private or restricted material' signals a boundary. But it never names an alternative or states when to prefer ask_company over this tool, so the agent must infer routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record interest in a company that isn't listed yet and get a link to share so it can publish its own trust center. No message is sent to the company.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| company_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish non-destructive, idempotent, closed-world behavior. The description adds genuinely new behavior: no notification is sent to the company, and a shareable link is returned. It doesn't specify what happens if the company is later listed or how the link behaves, keeping it short of a 5.
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 compact sentences, front-loaded with the action and result, with the key behavioral caveat last. No 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?
No output schema exists, and the description usefully covers the return value (a share link) and the side-effect profile. However, for a tool whose only required input is domain, leaving both parameters undocumented is a real gap 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?
Schema description coverage is 0% for two parameters, so the description carries the full burden — and it mentions neither domain nor company_name. An agent cannot tell from the text which field is required or what 'domain' means (bare hostname vs URL).
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 concrete action (record interest in an unlisted company) and its outcome (a shareable link for publishing a trust center). The 'isn't listed yet' clause implicitly separates it from find_company, though no sibling is named explicitly.
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?
Clearly establishes the condition for use: the company is not yet listed. The clarification 'No message is sent to the company' further distinguishes it from ask_company, which presumably does contact the company. No explicit exclusion sentence, but the context is inferable.
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.
ask_companyfind_companyget_trust_profileinvite_companyRead-only gateway for durable agent identity, consent, recognized work, and signed receipts.
Governed AI actions with signed, verifiable receipts: free keyless reads, human-approved writes.
Answers about your own company from its recorded knowledge, and shows where its sources disagree.
Check claims against a fact-store: consistent, contradicts, or unverifiable — with a receipt.
Add one secure layer between your agents and this server.
