Create and manage flashcards, tags, and saved decks in Nibomo, and study due cards one question at a time through MCP.
Scored across 8 tools
Each tool maps to a distinct step or resource: docs (get_guide), account metadata (get_usage_limits), workspaces (list_workspaces), and the sequential review loop (next_review_card → reveal_answer → submit_review), plus a clean read/write split between sql_query and sql_execute. The SQL pair is explicitly differentiated as read-only vs. write, and the review tools are ordered by their descriptions so an agent cannot reasonably pick the wrong one.
Most names follow verb_noun (get_guide, list_workspaces, reveal_answer, submit_review, next_review_card being a slight variant), but sql_execute and sql_query invert the pattern to noun_verb. The sql_ prefix makes the grouping readable, so this is a minor deviation rather than a confusing mix.
Eight tools is well-scoped for a spaced-repetition server: two documentation/meta tools, one account limit check, one workspace listing, three review-loop tools, and two SQL tools covering all authoring and querying. Nothing appears redundant or missing from the count perspective.
The surface covers the full lifecycle: discovery, card authoring/deletion (via sql_execute), reading (sql_query), and grading (next_review_card, reveal_answer, submit_review). Minor gaps exist—there is no way to set or change the default workspace, and no non-SQL convenience path for creating a single card or deck—but these are workable via the SQL tools.
Returns a Nibomo guide: study (explaining studying, nothing due), card_authoring (card rules, tags, duplicates, formatting, card links), bulk_authoring (large write jobs), review_flow (grading), sql_dialect (grammar, limits, examples).
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Guide topic. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is fully covered. The description's added value is scoping content ('nothing due' for study, 'tags, duplicates, formatting, card links' for card_authoring), but it doesn't say whether the guides are static text, versioned, or how large they are.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with the verb and resource front-loaded, followed by a tight five-item enumeration where every clause adds discriminating detail. No filler, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-value format need not be explained, and the topic content descriptions plus full schema coverage make the definition usable as-is. The only missing piece is guidance on ordering (e.g., read card_authoring before bulk_authoring).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the enum is self-explanatory, so the baseline is 3. The description goes beyond the terse 'Guide topic.' schema text by expanding what each of the five enum values actually covers, which helps an agent pick the right topic without guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Returns a Nibomo guide') and enumerates the five topic documents with parenthetical summaries, so an agent knows exactly what corpus it is retrieving. It never explicitly names a sibling tool, so it falls just short of full differentiation, but none of the siblings (sql_execute, submit_review, etc.) resemble a guide fetcher.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer it should pull 'card_authoring' before authoring cards or 'sql_dialect' before writing SQL, but nothing states when to call this versus just calling sql_query or submit_review directly. There are no explicit preconditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the user's plan, monthly AI limits and this month's AI usage. null aiMonthlyMessages means uncapped, not zero; aiMonthlyWeightedTokens and remainingWeightedTokens are always null. The month is UTC and resets at usage.monthEndsAt.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds critical behavioral details beyond annotations: null aiMonthlyMessages means uncapped rather than zero, weighted-token fields are always null, and the month is UTC with reset at usage.monthEndsAt. These caveats directly affect correct interpretation of the result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each front-loaded and useful: purpose first, then null-field interpretation, then month/reset semantics. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations, zero parameters, and an output schema, the description is complete enough. It supplements structured data with the non-obvious null and reset semantics an agent needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so the description has no parameter semantics to explain. The baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific read operation: returns the user's plan, monthly AI limits, and current-month AI usage. The resource and scope are unambiguous, and no sibling tool overlaps this usage/limits domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies when to use it, but there is no explicit usage guidance, trigger condition, or comparison with alternatives. With no close sibling, the implied usage is adequate but not richly specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the user's workspaces; isSelected marks the default used when workspaceId is omitted.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds behavioral context beyond that by explaining the isSelected flag's meaning and its link to omitting workspaceId elsewhere, which the annotations and schema do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single clause-and-a-half sentence with zero waste, front-loading the action and following with the one non-obvious semantic detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only listing tool with full annotation coverage and an output schema, the description covers everything an agent needs: what it returns and how the returned default interacts with other calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so the baseline is 4. The description uses the space instead to explain the cross-tool meaning of the returned isSelected field, adding value rather than restating the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Lists the user's workspaces') with the scope narrowed to the authenticated user. Sibling tools (sql_query, submit_review, etc.) are unrelated enough that no disambiguation is needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance, but the tool's purpose is narrow and the description adds a useful usage-adjacent fact: the isSelected default is what other calls fall back on when workspaceId is omitted, implying this is the discovery step before other calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the next card to review (cardId, frontText, no answer) in app queue order: due cards reviewed within an hour, other due cards, then new. card:null: nothing due in that selection (all cards when unfiltered); tell nextDueAt in the learner's timezone (null: none scheduled), don't re-call, and offer adding cards or ungraded practice (get_guide(study)).
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Match any existing workspace tag, case-insensitively. Unknown tags return 400; [] matches nothing. Cannot combine with deckId. | |
| deckId | No | Saved deck UUID (tag filter); no deck tags means all cards. Cannot combine with tags. | |
| workspaceId | No | Workspace UUID; omit for selected. Keep fixed through review/retries. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only and idempotent annotations, it discloses queue ordering, that no answer is included, null semantics, nextDueAt timezone handling, and a do-not-recall behavior. This is rich behavioral context that helps an agent invoke and follow up correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded with the main return behavior, then null handling and follow-up guidance. It is appropriately sized, though the shorthand 'card:null' and parenthetical callout reduce readability slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given rich schema coverage, annotations, and an output schema, the description is largely complete: it explains null results, nextDueAt, and not re-calling. It could better connect a successful card return to the reveal_answer and submit_review workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents tags, deckId, and workspaceId in detail. The description adds only a light reference to 'unfiltered' selection and does not meaningfully extend parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: returns the next review card, including cardId and frontText, explicitly without the answer. It also defines queue order and distinguishes the returned payload from a reveal-answer operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear guidance for the null case: tell nextDueAt, don't re-call, and offer adding cards or ungraded practice via get_guide(study). It does not explicitly state when to move to reveal_answer or submit_review, so sibling workflow guidance is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a card's backText to compare with the learner's attempt; call it only after they answer. Changes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| cardId | Yes | The cardId returned by next_review_card. | |
| workspaceId | No | Workspace UUID; omit for selected. Keep fixed through review/retries. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so "Changes nothing" is partly redundant reinforcement. The description adds value annotations cannot carry: the pedagogical/sequence constraint (reveal only after an attempt), which prevents an agent from short-circuiting the review loop.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with the return value first and the usage constraint second; nothing is padded and no clause could be removed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema covering return values, full schema coverage on both params, and annotations covering the safety profile, the description only needs to supply the workflow gate — which it does. Nothing material is missing for a correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters are documented in the schema itself (cardId sourced from next_review_card, workspaceId defaulting to selected). The description adds no format or defaulting detail beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a concrete verb+resource plus the field returned ("Returns a card's backText"), which is more specific than a bare 'get answer'. It also ties into the review flow by referencing the learner's attempt, though it does not explicitly name the sibling tools it complements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"call it only after they answer" gives an explicit precondition and implies the next_review_card → answer → reveal_answer sequence. It stops short of naming an alternative tool or a when-not-to-call case, but the ordering constraint is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates, updates or deletes cards and decks with Nibomo SQL INSERT, UPDATE or DELETE, not full PostgreSQL; cannot write review_events or FSRS state. New cards: front_text is a recall prompt, never the answer; at least one tag. One call is an atomic batch of up to 50 semicolon-separated writes, 100 affected rows each. Arrays: ('a', 'b'), or () to clear; filter UPDATE and DELETE by tag with tags OVERLAP ('tag'); RETURNING col1, col2 returns affected rows. After saving cards, tell how many and where they are (one card: its link, get_guide(card_authoring); many: data.reviewUrl, the Review page), and offer to study them now. ok true with data.rowsOmitted or top-level truncated true: the write landed; never resend it, SELECT to check.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | One or more semicolon-separated write statements. | |
| workspaceId | No | Workspace UUID from list_workspaces; omit for the selected default. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only flag destructive/not-read-only; the description adds real operational context: atomic batch limits, unsupported tables, and crucially the recovery semantics ('ok true with data.rowsOmitted or truncated true: the write landed; never resend it'). That prevented-duplicate-write guidance is exactly the kind of non-schema disclosure this dimension rewards.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but front-loaded: capability and limits lead, syntax rules follow, post-call behavior last. Every sentence carries information, though the array/RETURNING syntax block is packed tightly enough to read as a reference dump.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive write tool with an output schema, the description covers what can be written, batch limits, the partial-result flag, and the required follow-up message to the user. An agent has everything needed to call it correctly and to avoid a duplicate resend.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and only two params, but the description adds syntax meaning the schema lacks: array literals ('a','b') versus () to clear, tags OVERLAP filtering, and RETURNING columns. It doesn't elaborate on workspaceId, which the schema already covers well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence gives a specific verb set (INSERT/UPDATE/DELETE) against specific resources (cards and decks) and immediately bounds the dialect ('not full PostgreSQL') and excludes review_events and FSRS state. This is enough to distinguish it from the sibling sql_query (reads) without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states scope limits, the batching rule (max 50 statements, 100 rows each), how to filter UPDATE/DELETE by tag, and even the post-save reporting workflow. It never explicitly names sql_query as the alternative for reads, though 'SELECT to check' implies the split; that keeps it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only Nibomo SQL, not full PostgreSQL: SHOW TABLES, DESCRIBE, SHOW COLUMNS FROM and SELECT over workspace, cards, decks and review_events. A deck is a saved tag filter; cards have no deck_id. At most 100 rows per SELECT; paginate with ORDER BY, LIMIT, OFFSET; after data.rowsTruncated continue at OFFSET data.offset + data.rowCount. Run schema discovery in its own call. Grammar and examples: get_guide(sql_dialect).
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | One or more semicolon-separated read statements. | |
| workspaceId | No | Workspace UUID from list_workspaces; omit for the selected default. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnlyHint/idempotentHint annotations: it discloses the 100-row cap, the exact truncation signal (data.rowsTruncated) and resume protocol (OFFSET data.offset + data.rowCount), the dialect restrictions, and that schema discovery must be a separate call. It also pre-empts likely query mistakes by stating that a deck is a saved tag filter and cards have no deck_id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the most decision-relevant fact ('Read-only Nibomo SQL') and then packs limits, pagination, and domain caveats into a few dense sentences with no filler. Every clause—including the deck/cards note—prevents a concrete failure mode.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the description still clarifies the key response fields used for pagination (rowsTruncated, offset, rowCount), which is what an agent needs to loop correctly. Combined with dialect limits, table inventory, and the get_guide pointer, nothing needed to invoke it safely is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented, including the semicolon-separated statement semantics and the 'omit for the selected default' workspace behavior. The description adds dialect constraints on what the sql parameter may contain but no new per-parameter syntax or format detail, so this sits at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: read-only SQL over named tables (workspace, cards, decks, review_events), with an explicit scope boundary ('not full PostgreSQL') and an enumerated statement whitelist. It does not name the sibling sql_execute, so the read/write split is left to be inferred from the read-only framing rather than stated outright.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives actionable when-to-do-what: run schema discovery in its own call, consult get_guide(sql_dialect) for grammar and examples, and paginate with ORDER BY/LIMIT/OFFSET. It never explicitly says when to prefer sql_query over sibling sql_execute, which is the most likely routing ambiguity an agent would face.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Before the first grading in a conversation, read get_guide(review_flow) and follow it. Records the rating now and advances the card's authoritative FSRS schedule; returns the new schedule. Past reviews cannot be imported, and a saved review cannot be changed.
| Name | Required | Description | Default |
|---|---|---|---|
| cardId | Yes | The cardId returned by next_review_card. | |
| rating | Yes | Agent-assessed or manual learner rating: Again=any factual error or failed recall; Hard=correct but clearly uncertain about recall; Good=ordinary correct answer, including rough expression or modest hesitation; Easy=correct, confident, clear first attempt without evident extra thought. For a correct answer with unclear effort/confidence, use Good. Spoken aliases require learner agreement. | |
| reviewId | Yes | Persist this client-generated UUID before sending; reuse it on retries of this card's review to prevent duplicate reviews. | |
| workspaceId | No | Workspace UUID; omit for selected. Keep fixed through review/retries. | |
| reviewedTimeZone | Yes | Learner's IANA timezone, e.g. Europe/Sofia, for the local streak/progress day. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint, idempotentHint and a closed world, so the description's added value is in disclosing immutability ('a saved review cannot be changed') and that the updated schedule is returned. The retry/idempotency story is left to the schema, which is reasonable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with no wasted words. The prerequisite is front-loaded, though placing a precondition ahead of the purpose statement is slightly less scannable than leading with what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich schema and an output schema, the description only needed to cover the guide prerequisite, immutability, and the scheduling effect — all of which it does. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so every parameter including the rating enum and reviewId retry semantics is fully documented in the schema. The description adds no parameter-level detail beyond what is already structured, making 3 the correct baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Records the rating', 'advances the card's authoritative FSRS schedule') and names the effect and return value. It is clearly distinguishable from siblings like next_review_card or reveal_answer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit prerequisite ('Before the first grading in a conversation, read get_guide(review_flow) and follow it') and an exclusion ('Past reviews cannot be imported'). It does not explicitly contrast against sibling tools or state when grading should not be submitted, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_guide2 fields changedInput schema / properties / topic / enumPrevious value: -[
- "sql_dialect",
- "card_authoring",
- "bulk_authoring",
- "review_flow"
-]New value: +[
+ "study",
+ "sql_dialect",
+ "card_authoring",
+ "bulk_authoring",
+ "review_flow"
+]Output schema / properties / data / properties / topic / enumPrevious value: -[
- "sql_dialect",
- "card_authoring",
- "bulk_authoring",
- "review_flow"
-]New value: +[
+ "study",
+ "sql_dialect",
+ "card_authoring",
+ "bulk_authoring",
+ "review_flow"
+]next_review_card2 fields changedOutput schema / properties / data / properties / nextDueAtAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / data / requiredPrevious value: -[
- "workspaceId",
- "card"
-]New value: +[
+ "workspaceId",
+ "card",
+ "nextDueAt"
+]sql_execute2 fields changedInput schema / properties / sql / descriptionPrevious value: -"One or more write statements in the published Nibomo SQL dialect (INSERT, UPDATE, DELETE)."New value: +"One or more semicolon-separated write statements."Output schema / properties / data / anyOfPrevious value: -[
- {
- "properties": {
- "affectedCount": {
- "type": "number"
- },
- "normalizedSql": {
- "type": "string"
- },
- "resource": {
- "enum": [
- "cards",
- "decks"
- ],
- "type": "string"
- },
- "rows": {
- "items": {
- "additionalProperties": {
- "$ref": "#/definitions/__schema0"
- },
- "propertyNames": {
- "type": "string"
- },
- "type": "object"
- },
- "type": "array"
- },
- "rowsOmitted": {
- "type": "boolean"
- },
- "sql": {
- "type": "string"
- },
- "sqlOmitted": {
- "type": "boolean"
- },
- "statementType": {
- "enum": [
- "insert",
- "update",
- "delete"
- ],
- "type": "string"
- },
- "workspaceId": {
- "type": "string"
- }
- },
- "required": [
- "sql",
- "normalizedSql",
- "workspaceId",
- "statementType",
- "resource",
- "rows",
- "affectedCount",
- "rowsOmitted",
- "sqlOmitted"
- ],
- "type": "object"
- },
- {
- "properties": {
- "affectedCountTotal": {
- "type": "number"
- },
- "normalizedSql": {
- "type": "string"
- },
- "resource": {
- "type": "null"
- },
- "rowsOmitted": {
- "type": "boolean"
- },
- "sql": {
- "type": "string"
- },
- "sqlOmitted": {
- "type": "boolean"
- },
- "statementCount": {
- "type": "number"
- },
- "statementType": {
- "const": "batch",
- "type": "string"
- },
- "statements": {
- "items": {
- "additionalProperties": {},
- "properties": {
- "affectedCount": {
- "type": "number"
- },
- "resource": {
- "enum": [
- "cards",
- "decks"
- ],
- "type": "string"
- },
- "rows": {
- "items": {
- "additionalProperties": {
- "$ref": "#/definitions/__schema0"
- },
- "propertyNames": {
- "type": "string"
- },
- "type": "object"
- },
- "type": "array"
- },
- "statementType": {
- "enum": [
- "insert",
- "update",
- "delete"
- ],
- "type": "string"
- }
- },
- "required": [
- "statementType",
- "resource",
- "rows",
- "affectedCount"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "workspaceId": {
- "type": "string"
- }
- },
- "required": [
- "sql",
- "normalizedSql",
- "workspaceId",
- "rowsOmitted",
- "sqlOmitted",
- "statementType",
- "resource",
- "statementCount",
- "statements",
- "affectedCountTotal"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "properties": {
+ "affectedCount": {
+ "type": "number"
+ },
+ "normalizedSql": {
+ "type": "string"
+ },
+ "resource": {
+ "enum": [
+ "cards",
+ "decks"
+ ],
+ "type": "string"
+ },
+ "reviewUrl": {
+ "type": "string"
+ },
+ "rows": {
+ "items": {
+ "additionalProperties": {
+ "$ref": "#/definitions/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "rowsOmitted": {
+ "type": "boolean"
+ },
+ "sql": {
+ "type": "string"
+ },
+ "sqlOmitted": {
+ "type": "boolean"
+ },
+ "statementType": {
+ "enum": [
+ "insert",
+ "update",
+ "delete"
+ ],
+ "type": "string"
+ },
+ "workspaceId": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "sql",
+ "normalizedSql",
+ "workspaceId",
+ "statementType",
+ "resource",
+ "rows",
+ "affectedCount",
+ "rowsOmitted",
+ "sqlOmitted"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "affectedCountTotal": {
+ "type": "number"
+ },
+ "normalizedSql": {
+ "type": "string"
+ },
+ "resource": {
+ "type": "null"
+ },
+ "reviewUrl": {
+ "type": "string"
+ },
+ "rowsOmitted": {
+ "type": "boolean"
+ },
+ "sql": {
+ "type": "string"
+ },
+ "sqlOmitted": {
+ "type": "boolean"
+ },
+ "statementCount": {
+ "type": "number"
+ },
+ "statementType": {
+ "const": "batch",
+ "type": "string"
+ },
+ "statements": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "affectedCount": {
+ "type": "number"
+ },
+ "resource": {
+ "enum": [
+ "cards",
+ "decks"
+ ],
+ "type": "string"
+ },
+ "rows": {
+ "items": {
+ "additionalProperties": {
+ "$ref": "#/definitions/__schema0"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "statementType": {
+ "enum": [
+ "insert",
+ "update",
+ "delete"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "statementType",
+ "resource",
+ "rows",
+ "affectedCount"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "workspaceId": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "sql",
+ "normalizedSql",
+ "workspaceId",
+ "rowsOmitted",
+ "sqlOmitted",
+ "statementType",
+ "resource",
+ "statementCount",
+ "statements",
+ "affectedCountTotal"
+ ],
+ "type": "object"
+ }
+]sql_query1 field changedInput schema / properties / sql / descriptionPrevious value: -"One or more read statements in the published Nibomo SQL dialect (SHOW TABLES, DESCRIBE, SHOW COLUMNS, SELECT)."New value: +"One or more semicolon-separated read statements."submit_review1 field changedInput schema / properties / rating / descriptionPrevious value: -"Agent-assessed or manual learner rating: Again=failed recall; Hard=correct but difficult; Good=correct; Easy=complete and effortless. Default to Good if effort is unclear. Spoken aliases require learner agreement."New value: +"Agent-assessed or manual learner rating: Again=any factual error or failed recall; Hard=correct but clearly uncertain about recall; Good=ordinary correct answer, including rough expression or modest hesitation; Easy=correct, confident, clear first attempt without evident extra thought. For a correct answer with unclear effort/confidence, use Good. Spoken aliases require learner agreement."get_guideget_usage_limitslist_workspacesnext_review_cardreveal_answersql_executesql_querysubmit_reviewRead, write, and conversationally review open-source flashcards through split read/write MCP tools.
Create and study EngrAmo spaced-repetition flashcards from your AI client.
Build and study spaced-repetition flashcards with your agent.
Language flashcards in your AI assistant: build decks, edit cards and review what's due in the chat.
Add one secure layer between your agents and this server.
