AITWIRE
Server Details
Business-published entity records with confirmation dates: look up, page feeds, check claims.
- Status
- Healthy
- Uptime
- 99.9% over 37 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-03-26
- URL
TDQS
Scored across 3 tools
Each tool serves a clearly distinct purpose: lookup finds the entity record, feeds pages through its content feeds, and grounding validates claims against the record. There is minimal overlap, and any relationship between lookup and feeds is explicitly clarified by their descriptions.
All tools share the consistent 'aitwire_' prefix and use snake_case, which creates a recognizable pattern. The minor inconsistency is that two tools use 'entity_' and one does not, but this does not hinder predictability or readability.
Three tools is well-scoped for a specialized verification service. Each tool contributes a necessary function without redundancy, making the set feel complete and focused.
The toolset covers the full workflow: lookup an entity, retrieve its feeds, and ground claims against its record. There are no obvious missing operations for the stated purpose of reading and verifying AITWIRE data.
Available Tools
3 toolsaitwire_entity_feedsARead-onlyInspect
Page an entity's structured feeds on AITWIRE — products, services, articles or locations (tenant_id comes from aitwire_entity_lookup).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max items (default 10) | |
| feed_type | Yes | ||
| tenant_id | Yes | AITWIRE tenant ID (from lookup) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds the dependency on aitwire_entity_lookup and the feed types, but does not describe pagination behavior (e.g., cursor-based vs offset) or the return structure. With annotations providing safety context, 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 sentence that packs essential information: purpose, feed types, and dependency. No filler 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?
The tool is simple (3 params, no output schema). The description covers purpose, types, and prerequisite, but omits the shape of the response or how paging works beyond 'limit'. Still, for a read-only list tool with strong annotations, it is mostly 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 schema already describes limit (default 10) and tenant_id (from lookup). The description reinforces the tenant_id source and enumerates the feed_type enum values, but does not add substantial new meaning beyond the schema's 67% coverage.
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 the specific verb 'Page' and clearly identifies the resource: 'an entity's structured feeds on AITWIRE'. It enumerates the feed types (products, services, articles, locations) and notes the tenant_id dependency, distinguishing it from sibling tools like aitwire_entity_lookup.
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 tells the agent that tenant_id comes from aitwire_entity_lookup, establishing a clear workflow prerequisite. However, it does not explicitly mention alternatives or 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.
aitwire_entity_lookupARead-onlyInspect
Look up a business, brand, organization, person, or website's business-supplied entity record on AITWIRE by domain or name — its confirmed description, feed URLs, and proof counts, each carrying the date it was confirmed. Returns no match for entities that have not published to AITWIRE.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Entity name (e.g. 'AITWIRE') | |
| domain | No | Domain (e.g. 'example.com') |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds value by disclosing that unmatched entities return no result and that results include confirmation dates. No contradictions with annotations.
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 fluff. Every sentence provides essential information: what the tool does, how to use it, and what to expect.
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?
Given the simplicity of the tool (2 optional parameters, no output schema), the description covers the returned fields and an important edge case (no match). Could mention behavior when both parameters are provided, but not necessary.
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 baseline is 3. Description does not add extra meaning beyond the schema's parameter descriptions.
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?
Description clearly specifies the verb 'look up', the target resource ('entity record on AITWIRE'), and the types of entities (business, brand, etc.). It differentiates from siblings by focusing on business-supplied records with confirmation dates.
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?
Description implies usage for basic entity lookup but does not explicitly differentiate from sibling tools like aitwire_entity_feeds or aitwire_grounding. It mentions that lookup is by domain or name and that only published entities are returned, providing context but no alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
aitwire_groundingARead-onlyInspect
Check whether a specific claim matches an entity's business-supplied record on AITWIRE. Returns verified / contradicted / unknown with a confidence score, so you can attribute the result.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | Claim to verify | |
| entity | Yes | Entity domain or name |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive. Description adds value by detailing return outcomes (verified/contradicted/unknown) and confidence score, and mentions attribution of results.
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 are concise and front-loaded, conveying purpose and output without unnecessary 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?
Without an output schema, the description compensates by specifying return types and confidence score, which is sufficient for a simple tool with two parameters.
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 provides descriptions for both parameters (100% coverage). The description does not add any additional meaning beyond what the schema already states.
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 checks a claim against an entity's record on AITWIRE, specifying it returns verified/contradicted/unknown with confidence score. It distinguishes from siblings (entity feeds and lookup) by focusing on verification.
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?
Implied usage for verifying claims against a business record, but no explicit guidance on when to use this tool vs. siblings, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
aitwire_entity_feeds1 field changed- changed
Input schema / properties / feed_type / enumPrevious value: -[ - "products", - "services", - "articles", - "locations", - "policies" -]New value: +[ + "products", + "services", + "articles", + "locations" +]
3 tool updates
- First observed
aitwire_entity_feeds - First observed
aitwire_entity_lookup - First observed
aitwire_grounding
Related MCP Connectors
Search and verify 360K+ business entities with trust scores and W3C credentials.
Machine-readable entity discovery with provenance, trust and verified source evidence.
Discover, read and book verified real-world businesses through one endpoint.
Contradiction-verified, freshness-SLA'd signed feed: per-record status + as-of date + receipt.
Related MCP Servers
- AlicenseAqualityCmaintenanceProvides AI agents with access to real, verifiable businesses with provenance and source URLs, enabling natural-language business search and profile retrieval.2MIT

BizVerify MCP Serverofficial
AlicenseAqualityDmaintenanceEnables AI agents to verify and search business entities across US state and international company registries, providing real-time confirmation of legal existence, status, and filings.9MIT- FlicenseNot gradedqualityBmaintenanceEnables agents to query a single-source ontology of types, entities, statements, evidence, and controlled vocabulary, including bitemporal "as of" and "as recorded" fact lookups. Supports writing by letting agents propose candidate statements while keeping approval, review transitions, and authoritative reasoning restricted to approved facts.-
- FlicenseNot gradedqualityBmaintenanceCross-checks company/entity records against 23 national commercial registries (GLEIF, SIRENE, VIES, TED, Companies House) to flag missing or inconsistent registrations. Free tier: 100 calls/month via hosted API.-
Glama MCP Gateway
Add one secure layer between your agents and this server.