Read-only facts about Grideōs from its signed, hash-chained ledger. Verify before you cite.
Scored across 7 tools
Most tools are clearly distinct: get_claim (retrieve one entry), list_claims (enumerate), verify_claim (recompute hash/signature), search_site (keyword search), and list_dispatches all have separate jobs. The only mild overlap is contact_info versus get_company_profile, since the profile also mentions contact, but the descriptions draw the boundary clearly (contact only vs. full identity/people/method).
Six of seven tools follow a clean verb_noun or verb_resource pattern (get_claim, get_company_profile, list_claims, list_dispatches, search_site, verify_claim). contact_info is the lone noun-only outlier, a minor deviation that doesn't hurt readability.
Seven tools is well-scoped for a read-only facts-ledger server: list/get/verify for the ledger, plus profile, contact, dispatches, and site search. Each tool earns its place with no obvious redundancy or padding.
For a read-only disclosure/verification domain, coverage is essentially complete: enumerate and fetch ledger entries, independently verify hashes and signatures, search the wider site, and retrieve dispatches, profile, and contact. The only absent capability (sending messages) is explicitly declared out of scope, so agents aren't left with dead ends.
Email, office address and the URL of the brief form. This server cannot send messages.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and non-open-world behavior, so the safety profile is covered. The description adds a genuinely new behavioral boundary — that the server cannot send messages — which prevents an agent from promising an email action. It does not describe the return shape beyond the field list.
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, no filler, with the returned content front-loaded and the capability caveat second. Every sentence carries 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?
For a zero-parameter, no-output-schema tool, the description adequately enumerates the returned fields (email, address, form URL) so the agent knows what to expect. It could note the read-only informational nature more explicitly, but nothing critical for invoking it 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 takes zero parameters, so there is nothing for the description to disambiguate. This is the baseline-4 case for a parameterless tool.
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 the exact resources returned (email, office address, brief-form URL), so an agent knows this is a static contact-details lookup rather than a messaging tool. It is clear but does not explicitly contrast itself with siblings like get_company_profile or search_site.
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: call this when the user needs contact details. The sentence 'This server cannot send messages' functions as a partial when-not constraint, steering agents away from expecting any outbound messaging. There is no explicit statement of when to prefer this over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one ledger entry by ID (for example GRD-007) with its evidence links, status, hash and the hash of the previous entry.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Claim ID such as GRD-007 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, idempotent, non-destructive lookup. The description adds useful disclosure about returned content, including evidence links, status, hash, and previous-entry hash.
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 redundant or wasted wording. It efficiently conveys the lookup key and the key returned 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?
For a one-parameter read-by-ID tool with annotations covering safety and no output schema, the description provides enough return-value detail for correct use. Missing behavior for nonexistent IDs is minor in this context.
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 schema already defines the single id parameter with an example. The description repeats the example but adds no additional meaning beyond the schema.
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: return one ledger entry by ID. The phrase "one ledger entry by ID" clearly distinguishes it from list_claims and other sibling 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?
The description implies usage by requiring an ID and giving an example, but it does not explicitly say when to use this tool instead of list_claims or verify_claim. No exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who Grideōs is: definition, legal entity, location, contact, people, applications, method and trust layer, with links.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description's contribution is scope of returned content, which is useful but does not add behavioral traits like freshness, caching, or failure modes.
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 with no waste, front-loaded with 'Who Grideōs is'. The colon-list is compact, though the fragment style is slightly clipped for a reader unfamiliar with the product.
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, idempotent info tool with no output schema, the description adequately previews the returned payload. It is complete enough to call correctly, though it omits any cross-reference to contact_info.
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 there is no parameter semantics to explain; the schema correctly declares an empty closed object. Baseline 4 applies for a no-argument tool.
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 enumerates exactly what the profile contains (definition, legal entity, location, contact, people, applications, method, trust layer), so an agent knows this is a broad company-profile read. It is a content list rather than an explicit verb+resource, and it does not contrast itself with the overlapping sibling contact_info.
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 when-to-use guidance and no mention of alternatives, even though contact_info clearly overlaps with the 'contact' portion of this payload. An agent gets no signal about when to prefer this tool over that sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the claims in the signed Grideōs facts ledger, optionally filtered by topic (identity, location, people, what, ironwall, programs, relationships, contact, machine-access, privacy, work). A superseded claim names the entry that replaced it.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Optional topic filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuine behavioral context: the ledger is signed, and superseded claims name their replacement, which shapes how the agent should interpret returned entries.
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, no filler, with the resource and the optional filter front-loaded. The topic list is long but carries necessary information that appears nowhere else.
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 read-only listing tool whose safety profile is fully covered by annotations, the description covers scope, filtering and one important return-shape nuance. It omits pagination, ordering and result volume, which is a minor gap given no output schema exists.
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 documents the single parameter only as 'Optional topic filter' with no enum, so the description's enumeration of valid topic values adds real semantic value beyond the schema. It does not explain matching behavior (exact vs partial) for the filter.
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 (List) and resource (claims in the signed Grideōs facts ledger), which cleanly separates it from the singular sibling get_claim. It does not name any sibling explicitly, but the list-vs-get distinction is inferable.
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 optional topic filter implies a browsing/scan use case, but there is no explicit when-to-use guidance, no exclusion, and no routing to alternatives such as get_claim or verify_claim. Usage is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dated Grideōs updates with titles, summaries and URLs, newest first.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: the result shape (titles, summaries, URLs) and the sort order (newest first), which matters for consuming the output.
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 resource and then the payload fields and ordering. Every clause earns its place and there is 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?
With no output schema and no parameters, the description carries the burden of describing the return contents and ordering, which it does. It could mention volume or result limits, but for a simple zero-arg listing tool it is essentially complete.
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 there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. Schema coverage is 100% and additionalProperties is false, so no parameter gaps remain.
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 resource (dated Grideōs updates) and what each item contains (titles, summaries, URLs), which is clearer than the bare name 'list_dispatches'. It does not differentiate from any sibling, but the siblings (claims, company profile, site search) are unrelated enough that routing confusion is unlikely.
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 statement of when to use this tool, when not to, or what alternative exists. An agent can infer it is the listing endpoint from the name, but nothing in the text provides usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword search across grideos.com answers, pages and dispatches. Returns short passages with their URLs for citation.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum passages to return (default 5) | |
| query | Yes | What to look for, in plain words |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that by disclosing the return shape ('short passages with their URLs for citation'), which matters since there is no output schema. It stops short of describing ranking behavior or result variability.
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, zero filler, with the scope of the search front-loaded before the return-shape detail. Every sentence 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 two-parameter, read-only search tool with full schema coverage and no output schema, the description covers purpose and return values adequately. The only missing piece is routing guidance against the list_*/get_* siblings that also expose dispatches and claims.
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% ('What to look for, in plain words' and the limit bounds/default), so the schema already carries parameter meaning. The description adds only the general notion of keyword matching, with no extra syntax, quoting, or query-construction guidance 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 (keyword search) and resource scope (grideos.com answers, pages and dispatches), which is clear and self-contained. It does not explicitly distinguish itself from siblings like list_dispatches or get_claim, so an agent must infer the boundary itself.
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 'Keyword search across grideos.com answers, pages and dispatches' implies when it applies (free-text lookup across content types), but there is no explicit when-to-use/when-not, no mention of alternatives like list_dispatches or get_claim, and no prerequisites stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recompute a ledger entry's SHA-256 hash and chain link, and optionally compare a quoted claim text with the ledger text. Returns where to verify the Ed25519 signature independently.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Claim ID such as GRD-007 | |
| text | No | Optional claim text to compare with the ledger |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description adds real substance: what is recomputed, that the signature check is left to the caller ('verify the Ed25519 signature independently'), and where to do it. It stops short of saying whether the tool itself reports a pass/fail on the recomputed hash.
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, zero filler, with the core operation (recompute hash and chain link) front-loaded ahead of the optional comparison and return note.
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 the return-value burden and only partly does so: it says where to verify the signature externally but not what the tool returns on success or mismatch. For a verification tool whose whole value is the verdict, that gap matters.
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 100%, so both parameters are already documented, including the optional 'text' comparison. The description restates the text parameter's role without adding format or matching semantics, so the baseline 3 applies.
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?
Specific verb+resource: it states exactly what is recomputed (SHA-256 hash and chain link) and the optional text comparison, which clearly separates it from a plain retrieval tool like get_claim. It does not, however, explicitly name or contrast itself with any sibling.
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 rather than stated: recomputation and the optional 'quoted claim text' comparison signal an integrity/misquoting check, but the description never says when to call this instead of get_claim or list_claims. No prerequisites or exclusions are given.
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.
contact_infoget_claimget_company_profilelist_claimslist_dispatchessearch_siteverify_claimRead-only gateway for durable agent identity, consent, recognized work, and signed receipts.
Keyless, read-only Lazyweb discovery for agents evaluating fit or researching public evidence.
Read-only public financial evidence from LiquiLens, Undertow, Seiche and Palimpsest.
Verify official facts with Bitcoin-anchored proof. 180+ signals, x402 pay-per-call.
Add one secure layer between your agents and this server.
