A
licenseNot graded
qualityB
maintenanceProvides crypto market intelligence tools, reference resources, and prompt templates for sentiment analysis, mindshare tracking, social intelligence, and more.
39 npm
6
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 54 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A3.6/5.0
Scored across 12 tools
Disambiguation5/5
Each tool targets a distinct entity and action: get_ returns a single item, list_ returns collections, and me handles the current user. The get_project_series and get_topic_series are clearly scoped to different resources, so there is no meaningful overlap.
Naming Consistency4/5
The tool names follow a consistent verb_noun pattern with get_ and list_ prefixes. The single exception is 'me', which deviates from the pattern but is still predictable and readable.
Tool Count5/5
With 12 tools, the set is well-scoped for a crypto intelligence and attention tracking API. Each tool covers a meaningful resource or action, and the count is neither bloated nor insufficient.
Completeness4/5
Core resources like projects, topics, and intel have both list and get operations, and supporting features like vocabulary, clusters, reports, and account info are present. A minor gap is that reports can be fetched individually but cannot be listed, which may require agents to discover report IDs through other resources.
Available Tools
12 toolsget_intelGet intel detailsCRead-onlyInspect
Get one development with its sources and context.
ParametersJSON Schema
| 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
ParametersJSON 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 detailsARead-onlyInspect
Get a Project with recent Intel and related Projects.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| idOrSlug | Yes | Project ID or slug; slug aliases resolve |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it's a safe read. The description adds behavioral detail about returning 'recent Intel and related Projects', which is helpful beyond the annotations. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the primary action and includes key qualifiers. No wasted words; efficient and clear.
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?
Given the low complexity (1 parameter, output schema present), the description provides sufficient context for an agent to understand what the tool returns. The mention of 'recent Intel and related Projects' adds value without needing to duplicate 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 coverage is 100% with a clear description of idOrSlug. The tool description adds no additional parameter semantic value 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 clearly states it retrieves a single project along with recent intel and related projects, distinguishing it from sibling tools like list_projects (which lists projects) or get_intel (which gets only intel). However, it could be more precise about the scope of 'recent' and what 'related Projects' entails.
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 use when you need a single project with associated intel and related projects, but does not explicitly state when to use it versus alternatives like list_projects or get_project_series. No guidance on exclusions or preconditions is provided.
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.
ParametersJSON Schema
| 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
ParametersJSON 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Report ID |
Output Schema
ParametersJSON 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| topicId | Yes | Topic ID from list_topics |
Output Schema
ParametersJSON 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.
ParametersJSON Schema
| 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
ParametersJSON 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON 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 clustersARead-onlyInspect
List audience communities contributing to crypto attention.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| universe | No | Market universe (default: crypto) |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes |
TDQS
A3.6/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, so the agent knows this is a safe, non-destructive read operation. The description adds specificity that it lists 'audience communities contributing to crypto attention', which clarifies the scope beyond the annotations. No contradictions are present.
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 sentence of 7 words, which is concise and to the point. It front-loads the verb and resource. However, its brevity means it lacks detail that could add value, but it is not 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 low complexity (1 optional parameter, no required params, output schema present), the description is minimally adequate. The output schema likely covers the return structure, and annotations cover safety. However, the description could explain what 'audience clusters' are or how the 'universe' parameter affects results. For a simple tool, it is sufficient but not thorough.
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 schema already documents the 'universe' parameter with enum values and a description. The description adds no additional parameter semantics beyond what the schema provides, such as default behavior (default: crypto) which is not in the description. Baseline 3 is appropriate since the schema carries the full 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 states the verb 'list' and the resource 'audience clusters', but qualifies it with 'contributing to crypto attention', which narrows the scope and distinguishes it vaguely from siblings. However, it does not fully clarify what 'clusters' are in this context, and the sibling tools like 'list_projects' or 'list_topics' suggest overlapping listing functionality. The description is clear but lacks distinctiveness from other list tools.
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 this tool is for retrieving audience clusters related to crypto attention, and the input schema hints at filtering by 'universe' (crypto or tradfi). However, there is no explicit guidance on when to use this tool versus alternatives like 'list_intel' or 'list_projects'. No when-not-to-use or alternative suggestions are provided.
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.
ParametersJSON Schema
| 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
ParametersJSON 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 projectsARead-onlyInspect
Find tracked crypto Projects using supported filters.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | Comma-separated Project IDs | |
| sort | No | Order by trend (default), creation time, or latest reinforcement | |
| 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
ParametersJSON 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 and destructiveHint=false, indicating safe reads. The description adds no behavioral traits beyond stating it uses filters; but with 14 parameters and no mention of pagination, rate limits, or result completeness, the description does not significantly augment the annotation-provided safety profile.
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 short and front-loaded. Every word serves a purpose, but the phrase 'using supported filters' is redundant given the schema already enumerates filter parameters. A slight edge toward clarity could exist.
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 has 14 parameters with 100% schema coverage, a rich output schema, and annotations clearly stating it's read-only and non-destructive, the description captures the core intent. It is adequate for contextual completeness without needing to detail every filter.
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 each parameter is already documented in the schema. The description adds no new meaning beyond restating that filters are supported. The baseline of 3 is appropriate since the schema handles the burden fully.
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 lists tracked crypto projects using filters. The verb 'Find' and resource 'tracked crypto Projects' are specific, but the phrase 'using supported filters' is vague and does not distinguish from siblings like 'get_project', which retrieves a single project by ID.
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 usage for filtering projects but provides no explicit guidance on when to use this tool versus alternatives like 'get_project' for a single project or other list tools. Without exclusions or when-not-to-use instructions, the agent must infer context from sibling names.
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ranking | No | trend for sustained attention | trend |
| projectId | No | Only Topics currently associated with this Project ID |
Output Schema
ParametersJSON 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON 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.
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"
12 tool updates
- Changed
chat_with_aixbt1 field changed- changed
Input schema / properties / messages / descriptionPrevious value: -"Conversation history for Indigo (1-50 messages). First message is typically the user question."New value: +"Conversation turns to send, oldest first (1-50). Include prior turns for follow-up questions."
- Changed
get_intel2 fields changed- added
Input schema / properties / activity / descriptionAdded value: +"Activity rows to include: all (default), source observations only, or none" - changed
Input schema / properties / id / descriptionPrevious value: -"Intel id"New value: +"Intel ID"
- Changed
get_project1 field changed- changed
Input schema / properties / idOrSlug / descriptionPrevious value: -"Canonical Project id or slug"New value: +"Project ID or slug; slug aliases resolve"
- Changed
get_project_series4 fields changed- changed
Input schema / properties / from / descriptionPrevious value: -"Window start (ISO 8601)"New value: +"Start of time window (ISO 8601)" - changed
Input schema / properties / idOrSlug / descriptionPrevious value: -"Canonical Project id or slug"New value: +"Project ID or slug; slug aliases resolve" - changed
Input schema / properties / measure / descriptionPrevious value: -"Measurement series"New value: +"trend for hourly history; rank for recorded rank changes" - changed
Input schema / properties / to / descriptionPrevious value: -"Window end (ISO 8601)"New value: +"End of time window (ISO 8601)"
- Changed
get_report1 field changed- changed
Input schema / properties / id / descriptionPrevious value: -"Report id"New value: +"Report ID"
- Changed
get_topic1 field changed- changed
Input schema / properties / topicId / descriptionPrevious value: -"Topic id from list_topics"New value: +"Topic ID from list_topics"
- Changed
get_topic_series4 fields changed- changed
Input schema / properties / from / descriptionPrevious value: -"Window start (ISO 8601)"New value: +"Start of time window (ISO 8601)" - changed
Input schema / properties / measure / descriptionPrevious value: -"Measurement series"New value: +"trend for hourly history; rank for recorded rank changes" - changed
Input schema / properties / to / descriptionPrevious value: -"Window end (ISO 8601)"New value: +"End of time window (ISO 8601)" - changed
Input schema / properties / topicId / descriptionPrevious value: -"Known Topic id"New value: +"Topic ID"
- Changed
list_clusters1 field changed- added
Input schema / properties / universe / descriptionAdded value: +"Market universe (default: crypto)"
- Changed
list_intel21 fields changed- changed
Input schema / properties / activity / descriptionPrevious value: -"Evidence trail mode: all (default), observations, or none"New value: +"Activity rows to include: all (default), source observations only, or none" - changed
Input schema / properties / assetTypes / descriptionPrevious value: -"Comma-separated asset types (live reads only)"New value: +"Comma-separated asset types; use get_vocabulary to list them" - changed
Input schema / properties / categories / descriptionPrevious value: -"Comma-separated intel categories (discover via get_vocabulary)"New value: +"Comma-separated Intel category names; use get_vocabulary and choose intelCategories[].name" - changed
Input schema / properties / clusterIds / descriptionPrevious value: -"Comma-separated cluster ids"New value: +"Comma-separated cluster IDs" - changed
Input schema / properties / cursor / descriptionPrevious value: -"Opaque cursor from a previous page (meta.nextCursor)"New value: +"Cursor returned in meta.nextCursor from the previous page" - changed
Input schema / properties / detectedAfter / descriptionPrevious value: -"ISO 8601 lower bound"New value: +"Detected at or after this time (ISO 8601)" - changed
Input schema / properties / detectedBefore / descriptionPrevious value: -"ISO 8601 upper bound"New value: +"Detected at or before this time (ISO 8601)" - added
Input schema / properties / hasOfficialSource / descriptionAdded value: +"Set true to return only Intel with an official Project source" - added
Input schema / properties / limit / descriptionAdded value: +"Results per page (default and maximum: 50)" - added
Input schema / properties / minClusters / descriptionAdded value: +"Minimum number of community clusters represented" - changed
Input schema / properties / projectIds / descriptionPrevious value: -"Comma-separated Project ids"New value: +"Comma-separated Project IDs" - changed
Input schema / properties / projectRanking / descriptionPrevious value: -"Restrict to currently ranked Projects"New value: +"Only return Intel for Projects in the current trend ranking" - changed
Input schema / properties / reinforcedAfter / descriptionPrevious value: -"ISO 8601 lower bound"New value: +"Reinforced at or after this time (ISO 8601)" - changed
Input schema / properties / reinforcedBefore / descriptionPrevious value: -"ISO 8601 upper bound"New value: +"Reinforced at or before this time (ISO 8601)" - changed
Input schema / properties / search / descriptionPrevious value: -"Free-text deep search; combines with every other filter"New value: +"Any text to match across Project identity and Intel content; combines with all filters" - removed
Input schema / properties / search / maxLengthRemoved value: -200 - removed
Input schema / properties / search / minLengthRemoved value: -2 - changed
Input schema / properties / sort / descriptionPrevious value: -"Sort field (default: lastEvolvedAt)"New value: +"Order by latest content change (lastEvolvedAt, default), latest reinforcement, or first detection" - added
Output schema / properties / meta / properties / executedSearchAdded value: +{ + "description": "Normalized terms attempted within a bounded search", + "type": "string" +} - added
Output schema / properties / meta / properties / searchCoverageAdded value: +{ + "description": "Present when responsiveness bounds may omit matching results", + "enum": [ + "bounded_candidates", + "bounded_recent", + "bounded_candidates_recent" + ], + "type": "string" +} - added
Output schema / properties / meta / properties / searchQueryAdded value: +{ + "description": "Normalized query requested by the caller", + "type": "string" +}
- Changed
list_projects8 fields changed- changed
Input schema / properties / categories / descriptionPrevious value: -"Comma-separated canonical category slugs"New value: +"Comma-separated Project category slugs; use get_vocabulary to list them" - changed
Input schema / properties / cursor / descriptionPrevious value: -"Opaque cursor from a previous page (meta.nextCursor)"New value: +"Cursor returned in meta.nextCursor from the previous page" - added
Input schema / properties / hasToken / descriptionAdded value: +"Only include Projects with (true) or without (false) a token" - changed
Input schema / properties / ids / descriptionPrevious value: -"Comma-separated Project ids"New value: +"Comma-separated Project IDs" - changed
Input schema / properties / limit / descriptionPrevious value: -"Results per page (default: 50, max: 50)"New value: +"Number of results to return (default and maximum: 50)" - changed
Input schema / properties / minTrend / descriptionPrevious value: -"Minimum canonical trend measurement"New value: +"Minimum current trend score from 0 to 100" - changed
Input schema / properties / sort / descriptionPrevious value: -"Sort field (default: trend)"New value: +"Order by trend (default), creation time, or latest reinforcement" - added
Input schema / properties / universe / descriptionAdded value: +"Market universe (default: crypto)"
- Changed
list_reports5 fields changed- changed
Input schema / properties / cursor / descriptionPrevious value: -"Opaque cursor from a previous page (meta.nextCursor)"New value: +"Cursor returned in meta.nextCursor from the previous page" - added
Input schema / properties / limit / descriptionAdded value: +"Results per page (default and maximum: 50)" - added
Input schema / properties / projectId / descriptionAdded value: +"Only reports for this Project ID" - added
Input schema / properties / projectSlug / descriptionAdded value: +"Only reports for this Project slug" - added
Input schema / properties / topicId / descriptionAdded value: +"Only reports for this Topic ID"
- Changed
list_topics1 field changed- changed
Input schema / properties / projectId / descriptionPrevious value: -"Project id: serve the Topics associated with it"New value: +"Only Topics currently associated with this Project ID"
Related MCP Connectors
Crypto market intelligence: social sentiment, on-chain, trending narratives & analyst insights.
Crypto fundamentals, sentiment, whale tracking and influencer call accuracy for traders and agents.
Crypto market intelligence: regime detection, funding rates, liquidations, prices, signals.
Crypto market intelligence: prices, funding rates, narratives, regime, and delta-neutral research.
Related MCP Servers
- 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.77 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.28 npmMIT
- AlicenseAqualityAmaintenancePre-computed financial market intelligence for AI agents. Stocks, crypto, and ETFs.9123 npm5MIT
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.