A
licenseNot graded
qualityB
maintenanceProvides crypto market intelligence tools, reference resources, and prompt templates for sentiment analysis, mindshare tracking, social intelligence, and more.
17 npm
7
MIT
AIXBT
Server Details
Crypto market intelligence for Projects, Topics, Intel, Reports, and Clusters.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 99.9% over 75 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A3.5/5.0
Scored across 12 tools
Disambiguation4/5
Tools target distinct entities (intel, project, topic, report, cluster) and mostly distinct actions (get vs list vs series). Slight overlap between get_* and list_* pairs for intel/projects/topics, but descriptions clarify scope.
Naming Consistency4/5
Consistent get_/list_ + noun pattern across 11 of 12 tools; 'me' is a minor outlier that breaks the verb_noun convention.
Tool Count5/5
12 tools is well within the ideal 3-15 range for a read-only intelligence API, and each tool maps to a distinct resource or auxiliary lookup.
Completeness4/5
Core read paths for intel, projects, topics, series, clusters, and account are covered, but there is no list_reports to discover report IDs (get_report requires an ID) and no get_cluster detail, leaving minor dead ends.
Available Tools
12 toolsget_intelGet intel detailsCRead-onlyInspect
Get one development with its sources and context.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Exact Intel item id returned by list_intel, not its project.id | |
| activity | No | Activity rows to include: all (default), source observations only, or none |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes |
TDQS
C2.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that the result embeds sources and context (an expansion behavior beyond a plain record fetch), which is genuinely useful, but says nothing about permissions, size of the embedded payload, or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single economical sentence with no filler, and the core action leads. It is arguably too terse, but nothing is wasted or buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the annotation covers safety. What remains thin is orientation: the description never ties 'development' to the intel concept or explains the consequence of the activity enum, leaving a minor but real gap for a tool whose id semantics are already error-prone.
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%, and the schema is unusually good — it warns that the id must be the Intel item id 'not its project.id' and enumerates the activity modes. The description adds no parameter meaning beyond that, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a verb (Get) and a singular resource, but calls the resource a 'development' while the tool and its sibling list_intel deal in 'intel' items, so the agent must infer the two are the same thing. It does clarify the retrieval is one item including its sources and context, which is more than a bare restatement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance and no alternatives named. The pairing with list_intel in the sibling list implies a follow-up single-item fetch, but nothing in the description says when this is preferable or what conditions require it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_projectGet project detailsBRead-onlyInspect
Get a Project with recent Intel and related Projects.
| Name | Required | Description | Default |
|---|---|---|---|
| idOrSlug | Yes | Project ID or slug; slug aliases resolve |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
TDQS
B3.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact, that the response aggregates recent Intel and related Projects, but says nothing about auth, freshness/staleness, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no filler. It is arguably too terse for the routing decisions an agent faces, but every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema and annotations are rich, so return values and safety need not be explained, and the single parameter is fully documented. The remaining gap is routing context versus the many get_*/list_* siblings, which the description never addresses.
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?
With a single parameter at 100% schema coverage, the schema already documents idOrSlug and its slug-alias resolution behavior. The description adds no additional parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Get a Project') and clarifies the payload includes recent Intel and related Projects, which separates it from get_intel. It does not, however, distinguish itself from siblings like get_project_series or list_projects, so an agent still has to guess at the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance at all: nothing says when to pick get_project over list_projects or get_project_series, and no prerequisites (e.g., needing a valid id/slug) are mentioned. Usage must be inferred entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_project_seriesGet project historyBRead-onlyInspect
Get recent attention history for a Project.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End of time window (ISO 8601) | |
| from | No | Start of time window (ISO 8601) | |
| measure | Yes | trend for hourly scores; rank for recorded Trend-rank changes | |
| idOrSlug | Yes | Project ID or slug; slug aliases resolve |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
TDQS
B3.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, covering the safety profile. The description adds 'recent' implying a time constraint but does not elaborate on bounds, pagination, or output behavior. With annotations present, the description is adequate but adds little beyond the abstract term 'attention history.'
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, front-loaded sentence that efficiently conveys the core purpose. It contains no unnecessary words or redundancy. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (so return values are covered), 4 parameters with optional time window, and an enum, the description is adequate but incomplete. It does not mention the from/to filtering capability or default behavior. 'Recent' is vague, leaving the agent to infer that from/to control the window.
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 the input schema fully documents all four parameters. The description adds no additional meaning about parameters (e.g., default time windows or the meaning of 'trend' vs 'rank'). Baseline 3 is appropriate given the schema handles the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'recent attention history for a Project,' using a specific verb and resource. It implies time-series data, which distinguishes it from sibling tools like get_project (static details) and get_topic_series (topic attention). However, it could more explicitly define 'attention history' or contrast with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of appropriate scenarios, prerequisites, or exclusions (e.g., 'use get_project for static info, get_topic_series for topics'). The agent receives no help in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_reportGet topic reportBRead-onlyInspect
Get a published AIXBT report with its sources.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Report ID |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes |
TDQS
B3.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one behavioral detail beyond that: only *published* reports are retrievable and sources are bundled in the response. It says nothing about error behavior for unpublished/unknown IDs, so it is only marginally above what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no filler. It is efficient, though extremely brief — there is little structure to evaluate beyond the single clause.
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?
With an output schema present, return values need not be described, and the single parameter is fully covered by the schema, so the description is nearly complete. The only missing piece is any signal about what happens when the ID is unknown or the report is unpublished.
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% and there is a single required 'id' string parameter, so the schema already documents the input fully. The description adds no format, prefix, or validity detail beyond the schema, which is the expected baseline of 3 in this situation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Get a ... report') and adds useful scope with 'published' and 'with its sources', which distinguishes it from sibling getters like get_topic or get_project. It stops short of explicitly naming which sibling to use instead, so it is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no mention of prerequisites, and no reference to the many sibling retrieval tools (get_intel, get_project, get_topic, etc.). The agent must infer from the name alone when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_topicGet topic detailsARead-onlyInspect
Get one current Topic with its recent context.
| Name | Required | Description | Default |
|---|---|---|---|
| topicId | Yes | Topic ID from list_topics |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the agent knows this is a safe read operation with bounded context. The description adds 'with its recent context,' which hints at temporal scoping, but does not elaborate on the behavior (e.g., how 'recent' is defined, or whether the topic is updated). No contradiction 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action. It is appropriately sized for a tool with one parameter and clear purpose, though it could be slightly more specific without bloat.
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 tool's simplicity (single parameter, clear schema, annotations for safety, and an output schema present), the description is adequate. It explains the core function and the 'recent context' aspect. The output schema exists, so return value details are not needed.
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% (the only parameter topicId has a pattern and description referencing list_topics). The description does not add any new meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get one current Topic with its recent context.' This clearly identifies the verb (Get), the resource (Topic), and distinguishes it from siblings like get_report or list_topics. The mention of 'recent context' adds specificity, but the scope is not fully elaborated (e.g., what constitutes 'context').
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?
The description implies that this tool is for retrieving a single topic, contrasting with list_topics (which likely returns many). However, there is no explicit guidance on when to use this tool versus siblings like get_topic_series or get_intel, nor any mention of prerequisites (e.g., topicId from list_topics is already in the schema).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_topic_seriesGet topic historyARead-onlyInspect
Get recent attention history for a Topic.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End of time window (ISO 8601) | |
| from | No | Start of time window (ISO 8601) | |
| measure | Yes | trend for hourly scores; rank for recorded Trend-rank changes | |
| topicId | Yes | Topic ID |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
TDQS
A3.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false, so the tool is clearly safe for reading. The description adds the behavioral context that this retrieves 'history' (time-series data), which is beyond what the annotations specify. There is no contradiction 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's purpose. It front-loads the key action and subject. It could potentially add a bit more context (e.g., what 'recent' means) without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown but present), the description need not detail return values. However, it provides no guidance on time window handling or the interpretation of 'recent', nor does it explain the two measure options. The description is adequate for a tool with strong schema coverage and annotations, but leaves the agent guessing on default behavior (e.g., what happens if 'from' or 'to' is omitted?)
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents all four parameters with descriptions and constraints. The description adds minimal parameter-specific value but confirms the overall intent ('recent attention history'). The measure enum is well-described, and date/time parameters are clearly specified. Baseline 3 plus minor extra context justifies 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get recent attention history for a Topic' clearly identifies the action (get) and resource (attention history for a topic). However, it uses the vague term 'recent' which is not precisely defined, and among siblings like 'get_topic' (which likely returns current state) and 'get_project_series', this does not strongly distinguish itself beyond the resource type.
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?
The description implies the tool is for retrieving time-series data ('recent attention history'), suggesting it is for historical queries rather than current state. However, it provides no explicit guidance on when to use this tool versus alternatives like 'get_topic' (current state), 'get_intel' (different resource), or 'get_report'. No exclusion criteria or context signals are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_vocabularyGet filter vocabularyBRead-onlyInspect
Get current supported filter values.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
TDQS
B3.3/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, covering the safety profile. The description adds the word 'current', implying values may change over time, which is useful context. No further behavioral traits are disclosed, but the combination of annotations and output schema keeps this at an adequate level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a parameterless read-only tool, though the sparse information could be enriched with minimal usage context without hurting clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-parameter read-only tool with an output schema, the description is minimally adequate. It states what is returned (filter values) and their dynamic nature, but does not place the vocabulary in the broader filtering workflow or whether it is global/scoped. The output schema fills return format details, but overall completeness is basic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There is nothing for the description to add beyond what the (empty) input schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('Get') and resource ('filter values'), clearly distinguishing from entity-specific siblings like get_intel or list_projects. The phrase 'current supported filter values' makes the purpose unambiguous, though it could explicitly mention the domain or context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings or alternatives. An agent must infer that filter vocabulary is a prerequisite or reference for other calls; there are no explicit when-to-use instructions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_clustersList audience clustersBRead-onlyInspect
List audience communities contributing to crypto attention.
| Name | Required | Description | Default |
|---|---|---|---|
| universe | No | Market universe (default: crypto) |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes |
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds no behavioral context beyond that—no pagination, ordering, or scope limits—so it contributes almost nothing on this dimension.
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?
A single short sentence with no filler, and the resource scope is front-loaded. Nothing could be trimmed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the operation is a simple read-only list with one optional param. However, the description gives no indication of what distinguishes a cluster from a topic or project, leaving the agent without enough context to choose confidently among siblings.
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% and the single 'universe' parameter has an enum and its own description, so the schema carries the full burden. The description never mentions the universe filter, adding no meaning beyond the schema; the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description pairs the verb "List" with a specific resource: "audience communities contributing to crypto attention." This distinguishes it reasonably well from siblings like list_topics, list_projects, and list_intel, though the mismatch between the tool name (clusters) and the phrasing (audience communities) requires a small inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives (list_topics, list_projects, get_vocabulary) and no prerequisites or exclusions. The word "List" implies a browsing/retrieval context, but that is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_intelSearch crypto intelBRead-onlyInspect
Search recent crypto developments using text and filters.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Order by first detection (default) or latest reinforcement | |
| limit | No | Results per page (default and maximum: 50) | |
| names | No | Comma-separated Project names | |
| cursor | No | Cursor returned in meta.nextCursor from the previous page | |
| grades | No | ||
| search | No | Any text to match across Project identity and Intel content; combines with all filters | |
| address | No | Token contract address | |
| tickers | No | Comma-separated tickers | |
| activity | No | Activity rows to include: all (default), source observations only, or none | |
| xHandles | No | Comma-separated X handles | |
| marketCap | No | Only return Intel for Projects whose current market cap is in this band: low (under $80M), mid ($80M to $500M), or large ($500M and above). Projects without a current market cap are excluded | |
| assetTypes | No | Comma-separated asset types; use get_vocabulary to list them | |
| categories | No | Comma-separated Intel category names; use get_vocabulary and choose intelCategories[].name | |
| clusterIds | No | Comma-separated cluster IDs | |
| projectIds | No | Comma-separated Project IDs | |
| sentiments | No | Comma-separated sentiments: positive, neutral, negative | |
| minClusters | No | Minimum number of community clusters represented | |
| projectSlugs | No | Comma-separated Project slugs | |
| detectedAfter | No | Detected at or after this time (ISO 8601) | |
| detectedBefore | No | Detected at or before this time (ISO 8601) | |
| projectRanking | No | Only return Intel for Projects in the current trend ranking | |
| reinforcedAfter | No | Reinforced at or after this time (ISO 8601) | |
| reinforcedBefore | No | Reinforced at or before this time (ISO 8601) | |
| hasOfficialSource | No | Set true to return only Intel with an official Project source |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
TDQS
B3.1/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 the safe-read nature is established. The description adds the 'recent' temporal scope, but does not disclose behavioral details such as pagination, default sorting, or how filters combine. Given the annotations, this is acceptable 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler and places the verb and resource first. It is concise and readable, though slightly generic given the tool's 24-parameter complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 24 parameters and a rich filter surface, the description provides only minimal orientation. It does not mention pagination, the need for get_vocabulary for certain filter values, or how this broad search relates to sibling tools. The schema compensates partially, but the description itself is too thin for this complexity.
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 96%, so the input schema already documents nearly every parameter. The description's phrase 'using text and filters' only loosely references the search and filter parameters without adding meaning beyond the schema. This matches the baseline expectation for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and resource ('recent crypto developments'), with 'using text and filters' indicating how. It is clear that this is a search/list operation over intel, though it does not explicitly differentiate itself from siblings like get_intel or list_topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_intel for a single item or list_topics/list_projects for other entity types. Usage is only implied by the word 'Search'; no exclusions or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_projectsFind crypto projectsBRead-onlyInspect
Find tracked crypto Projects using supported filters.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | Comma-separated Project IDs | |
| sort | No | Use rank for the canonical top-project leaderboard (ranked projects only, confidence band before score). trend sorts raw score (default); createdAt and reinforcedAt sort by time. | |
| chain | No | Chain to filter by (e.g. "ethereum", "solana") | |
| limit | No | Number of results to return (default and maximum: 50) | |
| names | No | Comma-separated Project names | |
| slugs | No | Comma-separated Project slugs | |
| cursor | No | Cursor returned in meta.nextCursor from the previous page | |
| address | No | Token contract address | |
| tickers | No | Comma-separated tickers | |
| minTrend | No | Minimum current trend measurement | |
| universe | No | Market universe (default: crypto) | |
| xHandles | No | Comma-separated X handles | |
| assetTypes | No | Comma-separated asset types (token, stablecoin, nft-collection) | |
| categories | No | Comma-separated Project category slugs; use get_vocabulary to list them |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
TDQS
B3.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety and scope are covered. The description only adds the 'tracked' qualifier on the project universe; it says nothing about pagination behavior or result ordering, though the schema's cursor and sort fields partially cover that. With annotations carrying the safety profile, this is a modest add.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler, which is efficient for a filter-driven list tool. It is arguably too thin for a 14-parameter tool, but nothing is redundant or buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 100% schema coverage, an output schema, and annotations, the structured data carries most of the load. However, for a 14-parameter listing tool, the description omits that all filters are optional and combinable, and gives no sense of what a result set contains beyond the output schema.
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% across all 14 parameters, so the schema already documents filter syntax, sort semantics, and pagination. The description adds nothing beyond 'supported filters', so the baseline 3 for high-coverage schemas applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Find) and resource (tracked crypto Projects) with scope 'tracked' and the mechanism 'using supported filters'. It is clear what the tool does, but it does not distinguish itself from siblings like get_project or list_clusters, leaving the agent to infer that this is the multi-result listing tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'using supported filters' gestures at usage but gives no when-to-use guidance, no alternatives (e.g. get_project for a single project, get_vocabulary for category slugs), and no exclusions. An agent gets no help choosing this over the other 11 sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_topicsList trending topicsBRead-onlyInspect
List the current crypto Topic landscape.
| Name | Required | Description | Default |
|---|---|---|---|
| ranking | No | trend for sustained attention | trend |
| projectId | No | Only Topics currently associated with this Project ID |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
TDQS
B3.1/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 the tool is clearly safe to call. The description adds the time dimension ('current') and the domain ('crypto'), but does not disclose if results are paginated, cached, or if there's any rate limiting. Since annotations cover the key safety info, the description gets a 3 for adding some context without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at just 6 words, with no wasted sentences. It quickly states the tool's action and domain. However, it could be slightly more specific about what 'Topic landscape' entails without sacrificing conciseness (e.g., 'List currently trending crypto topics').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only 2 parameters (0 required), a clear output schema, and read-only annotations, the tool is simple and the description is mostly adequate. The output schema likely handles return values, so no need to describe them. However, the description's vagueness about what 'Topic landscape' means leaves some ambiguity about the scope of results, especially given sibling tools like list_intel that could overlap.
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 coverage is 100%, so both parameters are already documented in the schema with names, types, descriptions, and one enum. The description mentions 'current' but does not add any detail about the 'ranking' or 'projectId' parameters beyond what the schema provides. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List the current crypto Topic landscape' clearly identifies the tool's verb (List) and resource (Topic landscape), but it uses the vague phrase 'Topic landscape' which could mean different things. The title says 'trending topics', but the description does not reinforce that the list is specifically trending. Compared to siblings like list_intel and list_projects, this description does not explicitly differentiate itself.
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?
The description implies that the tool is used to see current crypto topics, but there is no guidance on when to use this tool versus siblings like list_intel or get_topic. No exclusions, prerequisites, or contextual alternatives are mentioned. The tool is non-destructive with no required params, so usage seems simple but lacks explicit when-to-use direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meCheck AIXBT accountARead-onlyInspect
Check the signed-in AIXBT account, plan, wallet, and usage limits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's 'Check' verb is fully consistent with that. It adds value by disclosing what the check surfaces (plan, wallet, usage limits), and implicitly signals authentication is required via 'signed-in'. No contradiction.
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?
A single, front-loaded sentence with zero wasted words. The verb and resource lead, and the coverage list is compact. Nothing could be trimmed without losing meaning.
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?
An output schema exists, so return values are documented elsewhere. With no parameters and a clear statement of what the tool checks, the description is essentially complete; the only minor gap is that it does not explicitly state authentication is required, though 'signed-in' strongly implies it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the schema has nothing to document, so the baseline of 4 applies. The description's enumeration of what is checked (plan, wallet, usage limits) adds useful context about the operation's scope even though there are no inputs to clarify.
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?
States a specific verb ('Check') and a precise resource ('signed-in AIXBT account') and enumerates exactly what is covered (plan, wallet, usage limits). This distinguishes it from all siblings, which are data-query tools (get_intel, list_projects, get_report) — an agent can immediately tell this is the account/self tool.
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 'signed-in' qualifier makes clear this operates on the current authenticated session's account, implying it's for account-level status rather than data retrieval. No explicit alternatives or exclusions are named, but the context is strong enough that confusion with the data-focused siblings is unlikely.
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.
3 tool updates
- Changed
get_project2 fields changed- added
Output schema / properties / data / properties / rankBandAdded value: +{ + "enum": [ + "strong", + "corroborated" + ], + "type": "string" +} - changed
Output schema / properties / data / properties / universe / enumPrevious value: -[ - "crypto", - "tradfi" -]New value: +[ + "crypto" +]
- Changed
list_clusters2 fields changed- changed
Input schema / properties / universe / enumPrevious value: -[ - "crypto", - "tradfi" -]New value: +[ + "crypto" +] - changed
Output schema / properties / data / items / properties / universe / enumPrevious value: -[ - "crypto", - "tradfi" -]New value: +[ + "crypto" +]
- Changed
list_projects5 fields changed- changed
Input schema / properties / sort / descriptionPrevious value: -"Order by trend (default), creation time, or latest reinforcement"New value: +"Use rank for the canonical top-project leaderboard (ranked projects only, confidence band before score). trend sorts raw score (default); createdAt and reinforcedAt sort by time." - changed
Input schema / properties / sort / enumPrevious value: -[ - "trend", - "createdAt", - "reinforcedAt" -]New value: +[ + "rank", + "trend", + "createdAt", + "reinforcedAt" +] - changed
Input schema / properties / universe / enumPrevious value: -[ - "crypto", - "tradfi" -]New value: +[ + "crypto" +] - added
Output schema / properties / data / items / properties / rankBandAdded value: +{ + "enum": [ + "strong", + "corroborated" + ], + "type": "string" +} - changed
Output schema / properties / data / items / properties / universe / enumPrevious value: -[ - "crypto", - "tradfi" -]New value: +[ + "crypto" +]
1 tool update
- Changed
me9 fields changed- added
Output schema / properties / data / properties / accountAdded value: +{ + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "plan": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "endsAt": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "type": "string" + }, + "periodStart": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "renewsAt": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "status": { + "enum": [ + "active", + "trialing", + "past_due" + ], + "type": "string" + }, + "via": { + "enum": [ + "subscription", + "holding", + "grant" + ], + "type": "string" + } + }, + "required": [ + "name", + "via", + "status", + "periodStart", + "renewsAt", + "endsAt" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "wallet": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "chain": { + "type": "string" + }, + "last4": { + "type": "string" + } + }, + "required": [ + "chain", + "last4" + ], + "type": "object" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "id", + "plan", + "wallet" + ], + "type": "object" +} - removed
Output schema / properties / data / properties / credentialRemoved value: -{ - "additionalProperties": false, - "properties": { - "expiresAt": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "id": { - "type": "string" - }, - "name": { - "type": "string" - }, - "type": { - "type": "string" - } - }, - "required": [ - "id", - "type", - "expiresAt" - ], - "type": "object" -} - removed
Output schema / properties / data / properties / entitlementsRemoved value: -{ - "items": { - "type": "string" - }, - "type": "array" -} - removed
Output schema / properties / data / properties / history / properties / archiveAccessRemoved value: -{ - "type": "boolean" -} - removed
Output schema / properties / data / properties / history / properties / earliestAvailableAtRemoved value: -{ - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] -} - removed
Output schema / properties / data / properties / history / properties / enforcedRemoved value: -{ - "type": "boolean" -} - removed
Output schema / properties / data / properties / history / properties / enforcementAtRemoved value: -{ - "type": "string" -} - changed
Output schema / properties / data / properties / history / requiredPrevious value: -[ - "archiveAccess", - "enforced", - "lookbackDays", - "earliestAvailableAt", - "enforcementAt" -]New value: +[ + "lookbackDays" +] - changed
Output schema / properties / data / requiredPrevious value: -[ - "credential", - "entitlements", - "rateLimit", - "history" -]New value: +[ + "account", + "rateLimit", + "history" +]
1 tool update
- Changed
list_intel1 field changed- changed
Input schema / properties / marketCap / descriptionPrevious value: -"Only return Intel for Projects whose current market cap is in this band: low (under $80M), mid ($80M to $500M), or large ($500M and above). Projects without a known market cap are excluded"New value: +"Only return Intel for Projects whose current market cap is in this band: low (under $80M), mid ($80M to $500M), or large ($500M and above). Projects without a current market cap are excluded"
1 tool update
- Changed
list_intel1 field changed- changed
Input schema / properties / marketCap / descriptionPrevious value: -"Only return Intel for Projects whose current market cap is in this band: low (under $80M), mid ($80M to $1B), large ($1B and above). Projects without a known market cap are excluded"New value: +"Only return Intel for Projects whose current market cap is in this band: low (under $80M), mid ($80M to $500M), or large ($500M and above). Projects without a known market cap are excluded"
2 tool updates
- Changed
get_vocabulary2 fields changed- added
Output schema / properties / data / properties / marketCapBandsAdded value: +{ + "items": { + "type": "string" + }, + "type": "array" +} - changed
Output schema / properties / data / requiredPrevious value: -[ - "grades", - "sentiments", - "stances", - "assetTypes", - "projectSort", - "intelSort", - "activityModes", - "projectRankings", - "universes", - "seriesMeasures", - "alertTriggers", - "alertCadences", - "projectCategories", - "intelCategories", - "chains" -]New value: +[ + "grades", + "sentiments", + "stances", + "assetTypes", + "marketCapBands", + "projectSort", + "intelSort", + "activityModes", + "projectRankings", + "universes", + "seriesMeasures", + "alertTriggers", + "alertCadences", + "projectCategories", + "intelCategories", + "chains" +]
- Changed
list_intel1 field changed- added
Input schema / properties / marketCapAdded value: +{ + "description": "Only return Intel for Projects whose current market cap is in this band: low (under $80M), mid ($80M to $1B), large ($1B and above). Projects without a known market cap are excluded", + "enum": [ + "low", + "mid", + "large" + ], + "type": "string" +}
1 tool update
- Changed
get_intel1 field changed- changed
Input schema / properties / id / descriptionPrevious value: -"Intel ID"New value: +"Exact Intel item id returned by list_intel, not its project.id"
1 tool update
- Changed
get_report1 field changed- added
Output schema / properties / data / properties / researchAsOfAdded value: +{ + "type": "string" +}
2 tool updates
- Changed
list_intel1 field changed- removed
Input schema / properties / grades / descriptionRemoved value: -"Comma-separated grades: chipped, flawed, cut, polished, flawless"
- Removed
list_reports
7 tool updates
- Changed
get_project2 fields changed- removed
Output schema / properties / data / properties / emergenceRemoved value: -{ - "type": "number" -} - removed
Output schema / properties / data / properties / emergenceRankRemoved value: -{ - "type": "number" -}
- Changed
get_project_series4 fields changed- changed
Input schema / properties / measure / descriptionPrevious value: -"trend for hourly scores; emergence for retained pre-quarantine six-hour measurements (not breakout probabilities); rank for recorded Trend-rank changes"New value: +"trend for hourly scores; rank for recorded Trend-rank changes" - changed
Input schema / properties / measure / enumPrevious value: -[ - "trend", - "emergence", - "rank" -]New value: +[ + "trend", + "rank" +] - changed
Output schema / properties / data / properties / basis / enumPrevious value: -[ - "hourly", - "six_hourly", - "rank_transitions" -]New value: +[ + "hourly", + "rank_transitions" +] - changed
Output schema / properties / data / properties / measure / enumPrevious value: -[ - "trend", - "emergence", - "rank" -]New value: +[ + "trend", + "rank" +]
- Changed
get_topic1 field changed- removed
Output schema / properties / data / properties / emergenceRemoved value: -{ - "type": "number" -}
- Changed
get_topic_series4 fields changed- changed
Input schema / properties / measure / descriptionPrevious value: -"trend for hourly scores; emergence for retained pre-quarantine six-hour measurements (not breakout probabilities); rank for recorded Trend-rank changes"New value: +"trend for hourly scores; rank for recorded Trend-rank changes" - changed
Input schema / properties / measure / enumPrevious value: -[ - "trend", - "emergence", - "rank" -]New value: +[ + "trend", + "rank" +] - changed
Output schema / properties / data / properties / basis / enumPrevious value: -[ - "hourly", - "six_hourly", - "rank_transitions" -]New value: +[ + "hourly", + "rank_transitions" +] - changed
Output schema / properties / data / properties / measure / enumPrevious value: -[ - "trend", - "emergence", - "rank" -]New value: +[ + "trend", + "rank" +]
- Changed
list_intel2 fields changed- changed
Input schema / properties / projectRanking / descriptionPrevious value: -"Only return Intel for Projects in the current trend or emergence ranking; emergence currently returns no rows while recalibrating"New value: +"Only return Intel for Projects in the current trend ranking" - changed
Input schema / properties / projectRanking / enumPrevious value: -[ - "trend", - "emergence" -]New value: +[ + "trend" +]
- Changed
list_projects5 fields changed- removed
Input schema / properties / minEmergenceRemoved value: -{ - "description": "Minimum current emergence measurement; currently returns an empty page while recalibrating", - "type": "number" -} - changed
Input schema / properties / sort / descriptionPrevious value: -"Order by trend (default), emergence, creation time, or latest reinforcement; emergence currently returns an empty page while recalibrating"New value: +"Order by trend (default), creation time, or latest reinforcement" - changed
Input schema / properties / sort / enumPrevious value: -[ - "trend", - "emergence", - "createdAt", - "reinforcedAt" -]New value: +[ + "trend", + "createdAt", + "reinforcedAt" +] - removed
Output schema / properties / data / items / properties / emergenceRemoved value: -{ - "type": "number" -} - removed
Output schema / properties / data / items / properties / emergenceRankRemoved value: -{ - "type": "number" -}
- Changed
list_topics3 fields changed- changed
Input schema / properties / ranking / descriptionPrevious value: -"trend for sustained attention; emergence for the currently recalibrating board, which returns empty"New value: +"trend for sustained attention" - changed
Input schema / properties / ranking / enumPrevious value: -[ - "trend", - "emergence" -]New value: +[ + "trend" +] - removed
Output schema / properties / data / items / properties / emergenceRemoved value: -{ - "type": "number" -}
13 tool updates
- Changed
get_intel2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
get_project2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
get_project_series2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
get_report2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
get_topic2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
get_topic_series2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
get_vocabulary2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
list_clusters2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
list_intel2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
list_projects2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
list_reports2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
list_topics2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
me2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
2 tool updates
- Changed
get_topic1 field changed- changed
Output schema / properties / data / properties / report / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "id": { - "type": "string" - }, - "publishedAt": { - "type": "string" - }, - "title": { - "type": "string" - } - }, - "required": [ - "id", - "title", - "publishedAt" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "publishedAt": { + "type": "string" + }, + "revisedAt": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "title": { + "type": "string" + } + }, + "required": [ + "id", + "title", + "publishedAt", + "revisedAt" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
list_topics1 field changed- changed
Output schema / properties / data / items / properties / report / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "id": { - "type": "string" - }, - "publishedAt": { - "type": "string" - }, - "title": { - "type": "string" - } - }, - "required": [ - "id", - "title", - "publishedAt" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "publishedAt": { + "type": "string" + }, + "revisedAt": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "title": { + "type": "string" + } + }, + "required": [ + "id", + "title", + "publishedAt", + "revisedAt" + ], + "type": "object" + }, + { + "type": "null" + } +]
5 tool updates
- Changed
get_project_series1 field changed- changed
Input schema / properties / measure / descriptionPrevious value: -"trend for hourly scores; emergence for completed six-hour scores; rank for recorded Trend-rank changes"New value: +"trend for hourly scores; emergence for retained pre-quarantine six-hour measurements (not breakout probabilities); rank for recorded Trend-rank changes"
- Changed
get_topic_series1 field changed- changed
Input schema / properties / measure / descriptionPrevious value: -"trend for hourly scores; emergence for six-hour scores; rank for recorded Trend-rank changes"New value: +"trend for hourly scores; emergence for retained pre-quarantine six-hour measurements (not breakout probabilities); rank for recorded Trend-rank changes"
- Changed
list_intel1 field changed- changed
Input schema / properties / projectRanking / descriptionPrevious value: -"Only return Intel for Projects in the current trend or emergence ranking"New value: +"Only return Intel for Projects in the current trend or emergence ranking; emergence currently returns no rows while recalibrating"
- Changed
list_projects2 fields changed- changed
Input schema / properties / minEmergence / descriptionPrevious value: -"Minimum current emergence measurement"New value: +"Minimum current emergence measurement; currently returns an empty page while recalibrating" - changed
Input schema / properties / sort / descriptionPrevious value: -"Order by trend (default), emergence, creation time, or latest reinforcement"New value: +"Order by trend (default), emergence, creation time, or latest reinforcement; emergence currently returns an empty page while recalibrating"
- Changed
list_topics1 field changed- changed
Input schema / properties / ranking / descriptionPrevious value: -"trend for sustained attention; emergence for an experimental early-attention ranking signal"New value: +"trend for sustained attention; emergence for the currently recalibrating board, which returns empty"
7 tool updates
- Changed
get_project2 fields changed- added
Output schema / properties / data / properties / emergenceAdded value: +{ + "type": "number" +} - added
Output schema / properties / data / properties / emergenceRankAdded value: +{ + "type": "number" +}
- Changed
get_project_series6 fields changed- changed
Input schema / properties / measure / descriptionPrevious value: -"trend for hourly history; rank for recorded rank changes"New value: +"trend for hourly scores; emergence for completed six-hour scores; rank for recorded Trend-rank changes" - changed
Input schema / properties / measure / enumPrevious value: -[ - "trend", - "rank" -]New value: +[ + "trend", + "emergence", + "rank" +] - changed
Output schema / properties / data / properties / basis / enumPrevious value: -[ - "hourly", - "rank_transitions" -]New value: +[ + "hourly", + "six_hourly", + "rank_transitions" +] - changed
Output schema / properties / data / properties / measure / enumPrevious value: -[ - "trend", - "rank" -]New value: +[ + "trend", + "emergence", + "rank" +] - added
Output schema / properties / meta / properties / versionsAdded value: +{ + "additionalProperties": { + "type": "string" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" +} - added
Output schema / properties / meta / requiredAdded value: +[ + "versions" +]
- Changed
get_topic2 fields changed- added
Output schema / properties / data / properties / emergenceAdded value: +{ + "type": "number" +} - changed
Output schema / properties / data / requiredPrevious value: -[ - "id", - "rank", - "name", - "summary", - "trend", - "postCount", - "authorCount", - "lastSeenAt" -]New value: +[ + "id", + "rank", + "name", + "summary", + "postCount", + "authorCount", + "lastSeenAt" +]
- Changed
get_topic_series4 fields changed- changed
Input schema / properties / measure / descriptionPrevious value: -"trend for hourly history; rank for recorded rank changes"New value: +"trend for hourly scores; emergence for six-hour scores; rank for recorded Trend-rank changes" - changed
Input schema / properties / measure / enumPrevious value: -[ - "trend", - "rank" -]New value: +[ + "trend", + "emergence", + "rank" +] - changed
Output schema / properties / data / properties / basis / enumPrevious value: -[ - "hourly", - "rank_transitions" -]New value: +[ + "hourly", + "six_hourly", + "rank_transitions" +] - changed
Output schema / properties / data / properties / measure / enumPrevious value: -[ - "trend", - "rank" -]New value: +[ + "trend", + "emergence", + "rank" +]
- Changed
list_intel2 fields changed- changed
Input schema / properties / projectRanking / descriptionPrevious value: -"Only return Intel for Projects in the current trend ranking"New value: +"Only return Intel for Projects in the current trend or emergence ranking" - changed
Input schema / properties / projectRanking / enumPrevious value: -[ - "trend" -]New value: +[ + "trend", + "emergence" +]
- Changed
list_projects5 fields changed- added
Input schema / properties / minEmergenceAdded value: +{ + "description": "Minimum current emergence measurement", + "type": "number" +} - changed
Input schema / properties / sort / descriptionPrevious value: -"Order by trend (default), creation time, or latest reinforcement"New value: +"Order by trend (default), emergence, creation time, or latest reinforcement" - changed
Input schema / properties / sort / enumPrevious value: -[ - "trend", - "createdAt", - "reinforcedAt" -]New value: +[ + "trend", + "emergence", + "createdAt", + "reinforcedAt" +] - added
Output schema / properties / data / items / properties / emergenceAdded value: +{ + "type": "number" +} - added
Output schema / properties / data / items / properties / emergenceRankAdded value: +{ + "type": "number" +}
- Changed
list_topics3 fields changed- added
Input schema / properties / rankingAdded value: +{ + "default": "trend", + "description": "trend for sustained attention; emergence for an experimental early-attention ranking signal", + "enum": [ + "trend", + "emergence" + ], + "type": "string" +} - added
Output schema / properties / data / items / properties / emergenceAdded value: +{ + "type": "number" +} - changed
Output schema / properties / data / items / requiredPrevious value: -[ - "id", - "rank", - "name", - "summary", - "trend", - "postCount", - "authorCount", - "lastSeenAt" -]New value: +[ + "id", + "rank", + "name", + "summary", + "postCount", + "authorCount", + "lastSeenAt" +]
1 tool update
- Changed
list_projects4 fields changed- removed
Input schema / properties / hasTokenRemoved value: -{ - "description": "Only include Projects with (true) or without (false) a token", - "type": "boolean" -} - changed
Input schema / properties / minTrend / descriptionPrevious value: -"Minimum current trend score from 0 to 100"New value: +"Minimum current trend measurement" - removed
Input schema / properties / minTrend / maximumRemoved value: -100 - removed
Input schema / properties / minTrend / minimumRemoved value: -0
1 tool update
- Removed
chat_with_aixbt
1 tool update
- Changed
list_intel2 fields changed- changed
Input schema / properties / sort / descriptionPrevious value: -"Order by latest content change (lastEvolvedAt, default), latest reinforcement, or first detection"New value: +"Order by first detection (default) or latest reinforcement" - changed
Input schema / properties / sort / enumPrevious value: -[ - "lastEvolvedAt", - "reinforcedAt", - "detectedAt" -]New value: +[ + "reinforcedAt", + "detectedAt" +]
2 tool updates
- Changed
get_intel5 fields changed- added
Output schema / properties / data / properties / activity / items / additionalPropertiesAdded value: +false - removed
Output schema / properties / data / properties / activity / items / oneOfRemoved value: -[ - { - "additionalProperties": false, - "properties": { - "action": { - "const": "follow", - "type": "string" - }, - "clusters": { - "items": { - "additionalProperties": false, - "properties": { - "id": { - "type": "string" - }, - "name": { - "type": "string" - } - }, - "required": [ - "id", - "name" - ], - "type": "object" - }, - "type": "array" - }, - "detectedAt": { - "type": "string" - }, - "eventTime": { - "additionalProperties": false, - "properties": { - "reason": { - "const": "not_stated", - "type": "string" - }, - "status": { - "const": "unknown", - "type": "string" - } - }, - "required": [ - "status", - "reason" - ], - "type": "object" - }, - "headline": { - "type": "string" - }, - "occurredAt": { - "type": "string" - } - }, - "required": [ - "detectedAt", - "occurredAt", - "action", - "eventTime" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "action": { - "enum": [ - "observation", - "official_statement", - "correction", - "merge" - ], - "type": "string" - }, - "clusters": { - "items": { - "additionalProperties": false, - "properties": { - "id": { - "type": "string" - }, - "name": { - "type": "string" - } - }, - "required": [ - "id", - "name" - ], - "type": "object" - }, - "type": "array" - }, - "detectedAt": { - "type": "string" - }, - "eventTime": { - "oneOf": [ - { - "additionalProperties": false, - "properties": { - "at": { - "type": "string" - }, - "precision": { - "enum": [ - "instant", - "day", - "week", - "month" - ], - "type": "string" - }, - "relationToSource": { - "enum": [ - "current", - "historical", - "future" - ], - "type": "string" - }, - "status": { - "const": "instant", - "type": "string" - } - }, - "required": [ - "status", - "at", - "precision", - "relationToSource" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "endAt": { - "type": "string" - }, - "precision": { - "enum": [ - "day", - "week", - "month" - ], - "type": "string" - }, - "relationToSource": { - "enum": [ - "current", - "historical", - "future" - ], - "type": "string" - }, - "startAt": { - "type": "string" - }, - "status": { - "const": "interval", - "type": "string" - } - }, - "required": [ - "status", - "startAt", - "endAt", - "precision", - "relationToSource" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "relationToSource": { - "enum": [ - "before_post", - "after_post", - "around_post" - ], - "type": "string" - }, - "status": { - "const": "relative_unresolved", - "type": "string" - } - }, - "required": [ - "status", - "relationToSource" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "reason": { - "enum": [ - "not_stated", - "ambiguous", - "ongoing" - ], - "type": "string" - }, - "status": { - "const": "unknown", - "type": "string" - } - }, - "required": [ - "status", - "reason" - ], - "type": "object" - } - ] - }, - "headline": { - "type": "string" - }, - "occurredAt": { - "type": "string" - }, - "sentiment": { - "additionalProperties": false, - "properties": { - "value": { - "enum": [ - "positive", - "neutral", - "negative" - ], - "type": "string" - } - }, - "required": [ - "value" - ], - "type": "object" - }, - "source": { - "additionalProperties": false, - "properties": { - "official": { - "type": "boolean" - }, - "url": { - "type": "string" - } - }, - "required": [ - "url", - "official" - ], - "type": "object" - } - }, - "required": [ - "detectedAt", - "occurredAt", - "action" - ], - "type": "object" - } -] - added
Output schema / properties / data / properties / activity / items / propertiesAdded value: +{ + "action": { + "enum": [ + "observation", + "official_statement", + "correction", + "merge" + ], + "type": "string" + }, + "clusters": { + "items": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + } + }, + "required": [ + "id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "detectedAt": { + "type": "string" + }, + "eventTime": { + "oneOf": [ + { + "additionalProperties": false, + "properties": { + "at": { + "type": "string" + }, + "precision": { + "enum": [ + "instant", + "day", + "week", + "month" + ], + "type": "string" + }, + "relationToSource": { + "enum": [ + "current", + "historical", + "future" + ], + "type": "string" + }, + "status": { + "const": "instant", + "type": "string" + } + }, + "required": [ + "status", + "at", + "precision", + "relationToSource" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "endAt": { + "type": "string" + }, + "precision": { + "enum": [ + "day", + "week", + "month" + ], + "type": "string" + }, + "relationToSource": { + "enum": [ + "current", + "historical", + "future" + ], + "type": "string" + }, + "startAt": { + "type": "string" + }, + "status": { + "const": "interval", + "type": "string" + } + }, + "required": [ + "status", + "startAt", + "endAt", + "precision", + "relationToSource" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "relationToSource": { + "enum": [ + "before_post", + "after_post", + "around_post" + ], + "type": "string" + }, + "status": { + "const": "relative_unresolved", + "type": "string" + } + }, + "required": [ + "status", + "relationToSource" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "reason": { + "enum": [ + "not_stated", + "ambiguous", + "ongoing" + ], + "type": "string" + }, + "status": { + "const": "unknown", + "type": "string" + } + }, + "required": [ + "status", + "reason" + ], + "type": "object" + } + ] + }, + "headline": { + "type": "string" + }, + "occurredAt": { + "type": "string" + }, + "sentiment": { + "additionalProperties": false, + "properties": { + "value": { + "enum": [ + "positive", + "neutral", + "negative" + ], + "type": "string" + } + }, + "required": [ + "value" + ], + "type": "object" + }, + "source": { + "additionalProperties": false, + "properties": { + "official": { + "type": "boolean" + }, + "url": { + "type": "string" + } + }, + "required": [ + "url", + "official" + ], + "type": "object" + } +} - added
Output schema / properties / data / properties / activity / items / requiredAdded value: +[ + "action", + "detectedAt", + "occurredAt" +] - added
Output schema / properties / data / properties / activity / items / typeAdded value: +"object"
- Changed
list_intel5 fields changed- added
Output schema / properties / data / items / properties / activity / items / additionalPropertiesAdded value: +false - removed
Output schema / properties / data / items / properties / activity / items / oneOfRemoved value: -[ - { - "additionalProperties": false, - "properties": { - "action": { - "const": "follow", - "type": "string" - }, - "clusters": { - "items": { - "additionalProperties": false, - "properties": { - "id": { - "type": "string" - }, - "name": { - "type": "string" - } - }, - "required": [ - "id", - "name" - ], - "type": "object" - }, - "type": "array" - }, - "detectedAt": { - "type": "string" - }, - "eventTime": { - "additionalProperties": false, - "properties": { - "reason": { - "const": "not_stated", - "type": "string" - }, - "status": { - "const": "unknown", - "type": "string" - } - }, - "required": [ - "status", - "reason" - ], - "type": "object" - }, - "headline": { - "type": "string" - }, - "occurredAt": { - "type": "string" - } - }, - "required": [ - "detectedAt", - "occurredAt", - "action", - "eventTime" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "action": { - "enum": [ - "observation", - "official_statement", - "correction", - "merge" - ], - "type": "string" - }, - "clusters": { - "items": { - "additionalProperties": false, - "properties": { - "id": { - "type": "string" - }, - "name": { - "type": "string" - } - }, - "required": [ - "id", - "name" - ], - "type": "object" - }, - "type": "array" - }, - "detectedAt": { - "type": "string" - }, - "eventTime": { - "oneOf": [ - { - "additionalProperties": false, - "properties": { - "at": { - "type": "string" - }, - "precision": { - "enum": [ - "instant", - "day", - "week", - "month" - ], - "type": "string" - }, - "relationToSource": { - "enum": [ - "current", - "historical", - "future" - ], - "type": "string" - }, - "status": { - "const": "instant", - "type": "string" - } - }, - "required": [ - "status", - "at", - "precision", - "relationToSource" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "endAt": { - "type": "string" - }, - "precision": { - "enum": [ - "day", - "week", - "month" - ], - "type": "string" - }, - "relationToSource": { - "enum": [ - "current", - "historical", - "future" - ], - "type": "string" - }, - "startAt": { - "type": "string" - }, - "status": { - "const": "interval", - "type": "string" - } - }, - "required": [ - "status", - "startAt", - "endAt", - "precision", - "relationToSource" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "relationToSource": { - "enum": [ - "before_post", - "after_post", - "around_post" - ], - "type": "string" - }, - "status": { - "const": "relative_unresolved", - "type": "string" - } - }, - "required": [ - "status", - "relationToSource" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "reason": { - "enum": [ - "not_stated", - "ambiguous", - "ongoing" - ], - "type": "string" - }, - "status": { - "const": "unknown", - "type": "string" - } - }, - "required": [ - "status", - "reason" - ], - "type": "object" - } - ] - }, - "headline": { - "type": "string" - }, - "occurredAt": { - "type": "string" - }, - "sentiment": { - "additionalProperties": false, - "properties": { - "value": { - "enum": [ - "positive", - "neutral", - "negative" - ], - "type": "string" - } - }, - "required": [ - "value" - ], - "type": "object" - }, - "source": { - "additionalProperties": false, - "properties": { - "official": { - "type": "boolean" - }, - "url": { - "type": "string" - } - }, - "required": [ - "url", - "official" - ], - "type": "object" - } - }, - "required": [ - "detectedAt", - "occurredAt", - "action" - ], - "type": "object" - } -] - added
Output schema / properties / data / items / properties / activity / items / propertiesAdded value: +{ + "action": { + "enum": [ + "observation", + "official_statement", + "correction", + "merge" + ], + "type": "string" + }, + "clusters": { + "items": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + } + }, + "required": [ + "id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "detectedAt": { + "type": "string" + }, + "eventTime": { + "oneOf": [ + { + "additionalProperties": false, + "properties": { + "at": { + "type": "string" + }, + "precision": { + "enum": [ + "instant", + "day", + "week", + "month" + ], + "type": "string" + }, + "relationToSource": { + "enum": [ + "current", + "historical", + "future" + ], + "type": "string" + }, + "status": { + "const": "instant", + "type": "string" + } + }, + "required": [ + "status", + "at", + "precision", + "relationToSource" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "endAt": { + "type": "string" + }, + "precision": { + "enum": [ + "day", + "week", + "month" + ], + "type": "string" + }, + "relationToSource": { + "enum": [ + "current", + "historical", + "future" + ], + "type": "string" + }, + "startAt": { + "type": "string" + }, + "status": { + "const": "interval", + "type": "string" + } + }, + "required": [ + "status", + "startAt", + "endAt", + "precision", + "relationToSource" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "relationToSource": { + "enum": [ + "before_post", + "after_post", + "around_post" + ], + "type": "string" + }, + "status": { + "const": "relative_unresolved", + "type": "string" + } + }, + "required": [ + "status", + "relationToSource" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "reason": { + "enum": [ + "not_stated", + "ambiguous", + "ongoing" + ], + "type": "string" + }, + "status": { + "const": "unknown", + "type": "string" + } + }, + "required": [ + "status", + "reason" + ], + "type": "object" + } + ] + }, + "headline": { + "type": "string" + }, + "occurredAt": { + "type": "string" + }, + "sentiment": { + "additionalProperties": false, + "properties": { + "value": { + "enum": [ + "positive", + "neutral", + "negative" + ], + "type": "string" + } + }, + "required": [ + "value" + ], + "type": "object" + }, + "source": { + "additionalProperties": false, + "properties": { + "official": { + "type": "boolean" + }, + "url": { + "type": "string" + } + }, + "required": [ + "url", + "official" + ], + "type": "object" + } +} - added
Output schema / properties / data / items / properties / activity / items / requiredAdded value: +[ + "action", + "detectedAt", + "occurredAt" +] - added
Output schema / properties / data / items / properties / activity / items / typeAdded value: +"object"
Related MCP Connectors
Crypto market intelligence: social sentiment, on-chain, trending narratives & analyst insights.
Crypto market intelligence: news, whale transfers, derivatives pulse and live prices.
Crypto fundamentals, sentiment, whale tracking and influencer call accuracy for traders and agents.
Crypto market intelligence: regime detection, funding rates, liquidations, prices, signals.
Related MCP Servers
- AlicenseAqualityBmaintenanceRead-only cryptocurrency intelligence tools for AI agents, providing source-backed market research, evidence, and structured crypto data.2Apache 2.0
- AlicenseNot gradedqualityDmaintenanceProvides predictive crypto market intelligence synthesized from whale positions, developer activity, and behavioral demand signals. Enables convergence scoring, whale divergence detection, and risk radar through MCP tools.171 npmMIT
- AlicenseNot gradedqualityCmaintenanceDelivers real-time crypto market microstructure, derivatives, order flow CVD/OI regime classification, fear & greed sentiment, and whale tracking context, enabling traders to assess market regimes and complement charting tools.13 npmMIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.