A
licenseA
qualityC
maintenanceProvides AI agents with access to real, verifiable businesses with provenance and source URLs, enabling natural-language business search and profile retrieval.
2
MIT
AITWIRE
by com.aitwire
Server Details
Business-published entity records with confirmation dates: look up, page feeds, check claims.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max items (default 10) | |
| feed_type | Yes | ||
| tenant_id | Yes | AITWIRE tenant ID (from lookup) |
TDQS
A4/5.0
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Entity name (e.g. 'AITWIRE') | |
| domain | No | Domain (e.g. 'example.com') |
TDQS
A4/5.0
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | Claim to verify | |
| entity | Yes | Entity domain or name |
TDQS
A4/5.0
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
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.
Contradiction-verified, freshness-SLA'd signed feed: per-record status + as-of date + receipt.
Official-source US business, permit, and WHOIS evidence via read-only MCP tools.
Related MCP Servers
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- AlicenseAqualityBmaintenanceExposes 29 official business-registry actors as MCP tools for KYC/AML, beneficial-owner (UBO), credit-risk and adverse-media workflows across 11 jurisdictions (EU, US, UAE). Sourced via Apify; pay-per-result.386MIT
- AlicenseAqualityBmaintenanceProvides a compiled knowledge substrate, extracting atomic claims from an append-only capture log and querying a bitemporal claim graph over MCP. Read-only by default, with opt-in writes for trusted sources.4MIT
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4.2/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose: entity_lookup retrieves an entity record, entity_feeds pages structured content for that entity, and grounding checks a claim against the entity's record. No overlap or ambiguity.
Naming Consistency4/5
All tool names start with 'aitwire_' and use snake_case, but two include 'entity_' and one does not (aitwire_grounding). Minor inconsistency but still predictable and readable.
Tool Count5/5
With only 3 tools, the server is tightly scoped to entity verification and feed retrieval. Each tool is essential, and the count is ideal for this focused domain.
Completeness5/5
The tool surface covers the full workflow: lookup an entity, retrieve its feeds, and ground claims against its record. No obvious gaps for the stated purpose of verifying entity-supplied information.