A
licenseB
qualityA
maintenanceVerify a number before an agent asserts it — a Deflated Sharpe Ratio for backtest, plus eval-gap, subset-win, and judge-bias checks, with signed receipts anyone can verify offline.
34
MIT
One-Page Readiness Check — 10 Signals, Arabic or English
Server Details
Ten machine-readable signals on one public page: the top miss if any, and a receipt we re-verify.
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
TDQS
A4.5/5.0
Scored across 1 tool
Disambiguation5/5
With only one tool, there is no possibility of confusing it with others. The tool's description clearly specifies when it should be used, so there is no ambiguity in selection.
Naming Consistency5/5
The single tool name follows a consistent snake_case convention with a domain prefix. Since there is only one tool, there are no conflicting naming patterns to worry about.
Tool Count3/5
The server's purpose is extremely narrow—a single readiness check—so one tool could be justified. However, the count falls below the typical 3-15 tool range, making it feel thin and borderline.
Completeness5/5
The one tool encompasses the entire readiness-check workflow described by the server, including checking 10 signals and returning a finding with a receipt and acceptance condition. No obvious missing operations for the stated domain.
Available Tools
1 tooladvisors_store_readiness_checkCheck one public store page for one actionable readiness findingARead-onlyIdempotentInspect
Use only after the requester supplies a public page and asks for a read-only check. Returns at most one measured finding with a server-authenticated source receipt and the fixed acceptance condition.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A credential-free public HTTP(S) page. Private networks and non-standard web ports are rejected. | |
| language | No | Response language: ar or en. | ar |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| errors | No | |
| remedy | No | |
| schema | Yes | |
| status | Yes | |
| target | No | |
| finding | No | |
| surface | Yes | |
| evidence | No | |
| language | Yes | |
| acceptance | No | |
| imperative | No | |
| provenance | No | |
| measurement | No | |
| recheck_url | No | |
| not_measured | No | |
| proof_status | Yes | |
| score_percent | No | |
| source_receipt | No | |
| consent_receipt | No | |
| coverage_percent | No | |
| no_remedy_reason | No | |
| measurement_status | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, and destructive hints. The description adds meaningful output behavior: 'at most one measured finding with a server-authenticated source receipt and the fixed acceptance condition.' This is beyond the annotations and tells the agent what to expect from the result.
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, zero filler. The usage precondition is front-loaded, followed by the output guarantee. Every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with an output schema and complete annotations, the description fully covers what an agent needs: when to use it, what it returns, and the read-only nature. Nothing essential is missing.
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%: both parameters have clear descriptions, including the URL constraint (credential-free, rejects private networks/non-standard ports) and language enum. The tool description does not add parameter-specific details, so the baseline 3 applies—it neither harms nor enhances beyond schema.
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 title and description together clearly state the tool checks one public store page and returns at most one measured readiness finding. The verb 'check' + resource 'store page' + scope 'one... one...' is specific. With no siblings, it fully identifies the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use only after the requester supplies a public page and asks for a read-only check.' This gives a clear precondition and the only valid invocation context. It leaves no ambiguity about when to call 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
advisors_store_readiness_check3 fields changed- added
Output schema / $defs / RemedyOutputAdded value: +{ + "additionalProperties": false, + "description": "الكتلةُ التي تُغلق العطل — لا وصفُه.\n\nقِيس 2026-08-24 أنّ المخرَج يحمل `imperative` و`acceptance` ولا يحمل\nعلاجاً: نقول «ينقصك بيانٌ منظَّم» ونترك العميلَ يكتبه. وهذا تقريرٌ بثوبِ\nأداة، ويخالف `docs/مبدأ-الإصلاح-لا-التقرير.md`.\n\nولا يُبنى العلاجُ من جسد الصفحة: مخرَجُنا يدخل سياقَ مساعدٍ ذكيّ، والصفحةُ\nالمجلوبةُ مدخلٌ لا نملكه. فالمواضعُ تُترك للعميل يملؤها، ولا يُصدَّر منها\nإلا الأصلُ الذي سلّمه المتّصلُ بنفسه.", + "properties": { + "closes": { + "title": "Closes", + "type": "string" + }, + "code": { + "title": "Code", + "type": "string" + }, + "fill_in": { + "items": { + "type": "string" + }, + "title": "Fill In", + "type": "array" + }, + "format": { + "enum": [ + "html-head-block", + "new-file" + ], + "title": "Format", + "type": "string" + }, + "where": { + "title": "Where", + "type": "string" + } + }, + "required": [ + "closes", + "format", + "where", + "code", + "fill_in" + ], + "title": "RemedyOutput", + "type": "object" +} - added
Output schema / properties / no_remedy_reasonAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "No Remedy Reason" +} - added
Output schema / properties / remedyAdded value: +{ + "anyOf": [ + { + "$ref": "#/$defs/RemedyOutput" + }, + { + "type": "null" + } + ], + "default": null +}
1 tool update
- Changed
advisors_store_readiness_check2 fields changed- added
Output schema / $defs / ProvenanceOutputAdded value: +{ + "additionalProperties": false, + "description": "من قاس، وأين بقيّةُ القياس.\n\nقِيس 2026-08-23 أنّ المخرَج لا يحمل إلى المستخدم شيئاً سوى `recheck_url`\nوهو مسارُ آلةٍ لا وجهةُ إنسان: مساعدٌ ينادي الأداةَ فيرى المستخدمُ عطلاً\nواحداً، ولا يعرف من قاسه ولا أنّ تسعَ إشاراتٍ أخرى قِيست. فالاكتشافُ\nيتحوّل إلى صفرٍ بحكم البناء لا بحكم قلّة الطلب.\n\nوهذا **إسنادٌ لا إعلان**: اسمُ من قاس، ورابطُ الورقة الكاملة، وعددُ ما\nقِيس وما يُعاد منه. لا وعدَ ترتيبٍ ولا ذكرٍ ولا نيّةِ شراء — تلك يمنعها\nعقدُ الأداة، ولا يمسّها هذا الحقل.", + "properties": { + "full_sheet_url": { + "title": "Full Sheet Url", + "type": "string" + }, + "measured_by": { + "const": "Advisors AI", + "default": "Advisors AI", + "title": "Measured By", + "type": "string" + }, + "signals_measured": { + "minimum": 1, + "title": "Signals Measured", + "type": "integer" + }, + "signals_returned": { + "minimum": 1, + "title": "Signals Returned", + "type": "integer" + } + }, + "required": [ + "full_sheet_url", + "signals_measured", + "signals_returned" + ], + "title": "ProvenanceOutput", + "type": "object" +} - added
Output schema / properties / provenanceAdded value: +{ + "anyOf": [ + { + "$ref": "#/$defs/ProvenanceOutput" + }, + { + "type": "null" + } + ], + "default": null +}
1 tool update
- First observed
advisors_store_readiness_check
Related MCP Connectors
Deterministic claim verification with receipts across ~60 domains. No model in the loop.
Market evidence with receipts: every claim resolves to a real stored record you can fetch back.
Evidence observatory for agentic commerce: x402 preflight, receipt checks, settlement attestations.
Evidence-backed x402 web verification for AI agents, with auditable decisions for every condition.
Related MCP Servers
- FlicenseNot gradedqualityBmaintenanceAuditable AGI-2027 evidence: eight graded Situational Awareness predictions with pre-registered flip conditions, a 0-100 Thesis Tracker with full score history, and a public market-call ledger where misses stay published. Free, no auth, CC BY 4.0.-
- FlicenseNot gradedqualityCmaintenanceCryptographically anchored, tamper-evident evidence receipts for AI agents — verified run receipts, existence-at-time proofs, and cited answers from an anchored public record. Remote MCP with proof-gated settlement; attests existence and integrity, never truth.-
emilia-mcp-serverofficial
AlicenseAqualityAmaintenanceThe accountability layer for AI agents — a named human's signed yes before an agent does anything irreversible (payment, record change, deploy), then an offline-verifiable Trust Receipt. Apache-2.0, formally verified.3649Apache 2.0