Create songs from prompts or lyrics, check credits, and access your private song library through an OAuth-connected MCP server. Uses your existing Words into Music account, song credits and limits. Songs support English, Spanish, German, French and Brazilian Portuguese. Documentation: https://wordsintomusic.com/mcp/
Scored across 8 tools
Each tool maps to a distinct step or resource: credit check, text writing, song preparation, song starting, job polling, library listing/retrieval, and checkout. The only potentially confusable pair is prepare_song vs start_song, but their descriptions make the free-prepare vs credit-spending distinction explicit. get_song vs get_song_job is also clearly separated by owned-song vs in-flight job.
All eight tools follow a consistent snake_case verb_noun pattern (create_, get_, list_, prepare_, start_, write_). The naming is predictable and readable, with get_song/get_song_job forming a coherent family rather than a collision.
Eight tools is well within the sweet spot and each one earns its place in the write -> prepare -> start -> poll lifecycle plus library and billing operations. Nothing appears redundant or missing at the count level.
The surface covers the full core lifecycle: writing text, preparing a song, spending a credit to start it, polling the job, and retrieving/list songs, plus billing checkout and credit status. Minor gaps exist — no cancel/delete song, no job cancellation, and no offer-listing or subscription-management tool independent of get_account_usage.
Create a Stripe checkout link for this connected account without website sign-in. First get_account_usage for current offers and show the full charge, recurring billing interval and monthly song allowance. Call only after the user explicitly chooses the offer. Never purchase silently. The user completes payment on Stripe. Poll get_account_usage at least 15 seconds apart, at most 8 times, then stop and let the user retry later if payment is pending. Retry the original preparedRequestId once credits arrive. Does not charge a saved card or open the billing portal.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| offer | Yes | ||
| locale | Yes | en | |
| interval | No | ||
| confirmed | Yes | ||
| requestKey | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond annotations: user completes payment on Stripe, rate-limited polling of get_account_usage (≥15s apart, max 8), retry-once semantics after credits arrive, and no-silent-purchase guarantee. However it references a 'preparedRequestId' that does not exist in the schema (the param is requestKey), leaving the retry contract ambiguous.
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?
Purpose is front-loaded in the first clause and each subsequent sentence adds a distinct operational constraint (precondition, polling budget, retry). Slightly dense procedural prose, and the stray 'preparedRequestId' term is a wasted/confusing token.
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 6-param, 5-required, open-world mutation with no output schema, the description covers preconditions, user-facing flow, polling limits, and retry behavior well. The notable gap is what the tool returns (a checkout URL/identifier) and how kind/locale affect the result.
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 0%, so the description must carry parameter meaning; it partially does by implying offer comes from get_account_usage offers and that interval is the recurring billing interval. It says nothing about kind (subscription vs pack), locale, or the idempotency role of requestKey, and confirmed is only indirectly implied.
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 ('Create a Stripe checkout link for this connected account') plus a distinguishing scope clause ('without website sign-in'). It also explicitly delimits what it is not ('Does not charge a saved card or open the billing portal'), separating it from other billing-related actions.
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 explicit sequencing ('First get_account_usage...'), a precondition ('Call only after the user explicitly chooses the offer'), a prohibition ('Never purchase silently'), and negative boundaries ('Does not charge a saved card or open the billing portal'). Alternatives and when-not-to-call are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check available Words into Music song credits. Does not spend credits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds a genuinely useful behavioral fact beyond the annotations: it does not consume credits, which is the key concern for a credits endpoint and distinguishes it from the spending siblings.
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?
Two short sentences, front-loaded with the action and followed by the key constraint. 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?
For a parameterless read-only tool with no output schema, the description covers what the agent needs: what it checks and that it is free. It does not describe the returned credit format, but with no output schema that is a minor gap.
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 schema carries no semantics to compensate for and the baseline of 4 applies. There is nothing parameter-related that the description needs to add.
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 specific verb+resource: check available Words into Music song credits. Clear and unambiguous, and clearly distinct from the song-oriented siblings. It does not explicitly name a sibling alternative, which keeps it short of a 5.
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?
Use case is implied rather than stated: an agent can infer this is the way to inspect credits before invoking prepare_song or start_song. No explicit when-to-use or when-not-to-use guidance is given, though 'does not spend credits' implicitly contrasts it with the spend-capable siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one owned song and its private library link. Lyrics are included only if requested. Opening the link requires the owner's normal website login.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| includeLyrics | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe, idempotent, non-destructive read. The description adds genuinely new behavioral context: the returned library link is private and requires the owner's normal website login, and lyrics are only present conditionally. That auth/permission disclosure is exactly the kind of detail annotations cannot 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?
Three short sentences, no redundancy, with the core purpose front-loaded and the conditional/auth caveats following in order of importance.
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 no output schema, the description usefully previews what comes back (the song plus a private library link, lyrics conditionally). The only gap is any mention of the 'id' parameter's meaning or lookup behavior, but for a two-parameter read tool this is close to complete.
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 0%, so the description must carry parameter meaning. It explains includeLyrics ('lyrics are included only if requested') but says nothing about 'id', leaving half the parameters undocumented beyond their types. Partial compensation for the coverage gap.
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 ('Get one owned song') and clarifies the scope is a single item, which implicitly separates it from 'list_songs'. It does not explicitly name any sibling, so it stops short of a 5.
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?
'Lyrics are included only if requested' implies how the includeLyrics flag is used, and the login note is a prerequisite for actually consuming the returned link. However, there is no explicit when-to-use vs when-to-prefer-an-alternative guidance against siblings like list_songs or get_song_job.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check one of the connected user's song jobs. No credit cost. A ready result includes the private song-page link. Generation continues if chat closes; optional completion emails use the existing account preference. Do not promise proactive chat notifications or inline playback.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), but the description adds genuinely non-obvious traits: no credit cost, the ready result carries a private song-page link, generation survives chat closure, and completion emails follow the existing account preference. It also constrains what the agent should promise (no proactive notifications, no inline playback), which is useful behavioral framing. It stops short of describing polling/retry expectations or non-ready states.
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?
Five short sentences, front-loaded with the purpose and cost, and each subsequent sentence adds distinct information (result contents, async behavior, email preference, promise constraints). Slightly staccato, but nothing is redundant.
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 no output schema, the description correctly fills the gap by stating what a ready result contains and clarifying cost and async behavior. It omits what a pending/failed job looks like and whether the agent should re-poll, which leaves a modest gap for a polling-style tool.
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?
There is a single required jobId with 0% schema description coverage, so the description carries the full burden — but it only says the job belongs to the connected user and never explains where jobId comes from (presumably start_song) or its expected format. The one parameter that matters most is left ambiguous in both schema and prose.
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 with scope: 'Check one of the connected user's song jobs.' That distinguishes it from get_song (fetch a finished song), list_songs, start_song and prepare_song, though the differentiation is implied by 'job' rather than called out explicitly.
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 description implies this is a status-check on an in-flight job ('Generation continues if chat closes'), which suggests polling after start_song, but it never states when to call it versus get_song or how often to poll. No alternatives are named, so usage is inferred rather than guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the connected user's private songs, newest first, with bounded pagination. No credit cost.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | Yes | ||
| cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral facts: deterministic ordering ('newest first'), bounded pagination, and that the call carries no credit cost.
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?
Two short sentences, zero filler, with the resource and ordering front-loaded and no repetition of schema or annotations.
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 simple read-only list tool with full annotation coverage and no output schema, the description covers subject, ordering, pagination existence and cost. The only real gap is how to advance pagination with the cursor, which matters for repeated 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?
Schema description coverage is 0%, so the description must carry parameter meaning and largely does not. 'Bounded pagination' hints that limit and cursor exist and that result sets are capped, but neither the required limit bound (1-20, default 10) nor the cursor's opaque-token semantics are explained.
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 specific verb and resource ('List the connected user's private songs') plus scope and ordering ('newest first'). An agent can distinguish it from get_song (single song) and prepare_song/start_song (mutation/job tools), though no sibling is named explicitly.
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 scope phrase 'connected user's private songs' implies this is the browsing entry point before fetching or preparing a specific song, but the description never states when to use it instead of get_song or get_song_job. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare a song without spending a credit. Show the user its language, sound, duration and one-song credit cost before starting. Reuse the same requestId when retrying this exact request. Supported languages: English, Spanish, German, French, Brazilian Portuguese, Italian, Dutch, Polish, Swedish, Japanese, Korean. Does not clone voices or edit existing audio.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | ||
| uiLocale | Yes | en | |
| requestId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, but the description adds the crucial cost behavior (no credit charged), the retry contract tying requestId to idempotency, and the fact that it surfaces language, sound, duration and one-song cost before commitment. With no output schema, disclosing what the preview returns is genuinely valuable. It stops short of saying whether any server-side state is created by the preparation step.
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?
Four sentences, front-loaded with the no-cost hook, then the preview contents, then the retry rule, then scope limits. The 11-language enumeration is somewhat redundant with the schema enum but adds human-readable confirmation; otherwise there is little waste.
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 tool with a nested 8-field input, 0% schema coverage and no output schema, the description covers the value proposition, cost model and language support but omits the idea-vs-lyrics mode distinction that determines how the whole request is interpreted. Adequate orientation, but an agent could still mis-shape the input.
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 0%, so the description must carry the burden, and it only covers requestId (idempotent retry semantics) and partially language/duration. The nested input's core fields — mode ('idea' vs 'lyrics'), idea, lyrics, direction, instrumental, title — plus uiLocale are never explained, leaving the most decision-relevant parameter (mode) undocumented.
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 ('prepare a song') and immediately qualifies it with 'without spending a credit' plus 'before starting', which distinguishes this preflight step from actually launching generation (the job start_song implies). It also rules out two adjacent capabilities (voice cloning, audio editing). It never names start_song as the follow-up, so the sibling routing is implied rather than stated.
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 concrete operational guidance: call this before starting, and reuse the same requestId when retrying this exact request. Exclusions are stated ('does not clone voices or edit existing audio'). What's missing is an explicit pointer to the tool to call after this preview succeeds.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start the prepared song after the user has asked to generate it. Spends ONE purchased song credit. No free audio trial. If PAYMENT_REQUIRED, show current offers and use create_checkout_link only after the user chooses. Retrying the same preparedRequestId returns the same job and does not spend another credit. Returns promptly; check get_song_job after 15 seconds. Never create another request just because a call timed out.
| Name | Required | Description | Default |
|---|---|---|---|
| preparedRequestId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds the economics the annotations cannot express: one purchased credit per call, no free trial, and the precise idempotency contract that retrying the same preparedRequestId returns the same job without charging again. The timeout guidance and PAYMENT_REQUIRED branch are exactly the kind of failure-mode context an agent needs before a destructive, credit-spending call.
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-loaded with the action and the cost, then the failure branches. Nearly every sentence is an actionable rule, though 'No free audio trial' partially restates 'Spends ONE purchased song credit' and could be folded in.
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 no output schema, the description still conveys that the call returns promptly with a job that get_song_job can be polled, but it never states the returned shape (e.g. a job id) explicitly, leaving the agent to infer it from the retry sentence.
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 0%, so the description must carry the parameter, and it does explain the important semantic: preparedRequestId is an idempotency key whose reuse is safe. It never says where that ID comes from (presumably prepare_song), which leaves a small gap for an agent that doesn't already hold one.
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 (start) and resource (the prepared song) and scopes it to 'after the user has asked to generate it', which cleanly separates it from prepare_song (which only prepares) and get_song_job (which polls). An agent can pick it apart from all six siblings without opening a 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?
Gives explicit preconditions (user must have asked to generate), an explicit alternative for the PAYMENT_REQUIRED case (create_checkout_link, and only after the user chooses), a follow-up route (get_song_job after 15 seconds), and an explicit prohibition (never re-create a request because of a timeout).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write with a free Words into Music generator: lyrics (AI lyric generator), rap, diss track, country, drill, pop, R&B, love song, gospel, K-pop, rock, folk, jazz, trap or educational song lyrics, or song titles, band names, stage names, rap names, album names, playlist names or DJ names. Pick the generator with kind. Uses the account's daily writing allowance (3 a day on free accounts, 150 after any subscription or song pack purchase), never song credits, and makes no audio. Reuse the same requestId when retrying so a retry returns the same text without using the allowance again. Returns editable text; the user can turn lyrics into a song with prepare_song.
| Name | Required | Description | Default |
|---|---|---|---|
| idea | Yes | ||
| kind | Yes | ||
| language | Yes | en | |
| direction | Yes | ||
| requestId | Yes | da3fc064-d8a0-4d73-a4ea-7893c8cb9d86 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses daily allowance rates (3 free, 150 after subscription or song pack), that it never uses song credits, that it produces no audio, and that requestId reuse returns the same text without consuming the allowance again. This is rich behavioral context for a non-read-only but non-destructive generation tool.
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 purpose is front-loaded, but the description is a dense run-on that repeats many enum values from the schema in prose. The allowance and retry details are useful, yet the long genre list makes it less concise than it could be.
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?
It covers the important side effects, allowance behavior, retry idempotency, and return format, which is strong for a tool without an output schema. However, given five required parameters and 0% schema coverage, the description is incomplete on what idea, direction, and language mean and how they should be supplied.
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 0% and five parameters are required, but the description only explains kind (pick the generator) and requestId (reuse on retry). It does not explain idea, direction, or language, leaving a significant semantic gap that the schema does not fill.
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: write/generate text with a Words into Music generator, covering lyrics and name generators. It also distinguishes the output from sibling audio tools by saying it makes no audio and that prepare_song turns the result into a song.
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 makes clear this is for generating editable text and that prepare_song is the follow-up for turning lyrics into a song. It also explains the allowance model so the agent knows the cost context, though it does not explicitly enumerate when to choose this over every other sibling.
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.
write_text1 field changedInput schema / properties / requestId / defaultPrevious value: -"42de9d5b-f962-44d2-ac9f-d7f0263bb6bf"New value: +"da3fc064-d8a0-4d73-a4ea-7893c8cb9d86"write_text1 field changedInput schema / properties / requestId / defaultPrevious value: -"df65087a-506e-4181-9a3c-91ca6cbac798"New value: +"42de9d5b-f962-44d2-ac9f-d7f0263bb6bf"write_text1 field changedInput schema / properties / requestId / defaultPrevious value: -"6fb01aab-4fa0-43f5-850e-2acd9f61b79d"New value: +"df65087a-506e-4181-9a3c-91ca6cbac798"write_text1 field changedInput schema / properties / requestId / defaultPrevious value: -"77e5a4e3-2641-48ed-b579-eaf4c2c7c6cf"New value: +"6fb01aab-4fa0-43f5-850e-2acd9f61b79d"write_text1 field changedInput schema / properties / requestId / defaultPrevious value: -"24b152fe-d957-4f22-be96-a9d7173b33b4"New value: +"77e5a4e3-2641-48ed-b579-eaf4c2c7c6cf"write_text1 field changedInput schema / properties / requestId / defaultPrevious value: -"141b3253-17c6-48d0-9cfd-e81253337fc0"New value: +"24b152fe-d957-4f22-be96-a9d7173b33b4"write_text1 field changedInput schema / properties / requestId / defaultPrevious value: -"92397f08-44d1-42f2-960e-747ba51fdf91"New value: +"141b3253-17c6-48d0-9cfd-e81253337fc0"write_text1 field changedInput schema / properties / requestId / defaultPrevious value: -"539403c0-c5f1-4c07-b482-ba2f16de3c52"New value: +"92397f08-44d1-42f2-960e-747ba51fdf91"write_text1 field changedInput schema / properties / requestId / defaultPrevious value: -"54b0dff2-58ef-4847-8eb7-0f6593a293c2"New value: +"539403c0-c5f1-4c07-b482-ba2f16de3c52"write_text1 field changedInput schema / properties / requestId / defaultPrevious value: -"51db87d3-6a16-48f3-906e-55d7b31aa088"New value: +"54b0dff2-58ef-4847-8eb7-0f6593a293c2"write_text1 field changedInput schema / properties / requestId / defaultPrevious value: -"72ed0a2b-e368-42fd-ba98-fa947659a618"New value: +"51db87d3-6a16-48f3-906e-55d7b31aa088"write_text1 field changedInput schema / properties / requestId / defaultPrevious value: -"254d4396-790b-481d-b2d2-0ff529c0497d"New value: +"72ed0a2b-e368-42fd-ba98-fa947659a618"write_text1 field changedInput schema / properties / requestId / defaultPrevious value: -"8f239790-d74e-48eb-9cad-c677c008155f"New value: +"254d4396-790b-481d-b2d2-0ff529c0497d"write_text1 field changedInput schema / properties / requestId / defaultPrevious value: -"5fd6b4ff-f1cf-4258-92ef-df2945ba75f2"New value: +"8f239790-d74e-48eb-9cad-c677c008155f"write_text1 field changedInput schema / properties / requestId / defaultPrevious value: -"6e14c972-7640-43ce-837f-59da04e97e6b"New value: +"5fd6b4ff-f1cf-4258-92ef-df2945ba75f2"write_text1 field changedInput schema / properties / requestId / defaultPrevious value: -"6753f52d-1d24-4f97-919f-2f8c7ffdb6f4"New value: +"6e14c972-7640-43ce-837f-59da04e97e6b"write_text1 field changedInput schema / properties / requestId / defaultPrevious value: -"8229435b-06a6-4371-a3ce-ae861011bf12"New value: +"6753f52d-1d24-4f97-919f-2f8c7ffdb6f4"write_text1 field changedInput schema / properties / requestId / defaultPrevious value: -"f12d98bd-808c-48f1-98e9-88693198346e"New value: +"8229435b-06a6-4371-a3ce-ae861011bf12"write_text1 field changedInput schema / properties / requestId / defaultPrevious value: -"8d5b593c-47c8-492e-af88-fa7b459b7a37"New value: +"f12d98bd-808c-48f1-98e9-88693198346e"write_text1 field changedInput schema / properties / requestId / defaultPrevious value: -"efc39554-f040-4717-820b-90c83c3dff6e"New value: +"8d5b593c-47c8-492e-af88-fa7b459b7a37"
Add one secure layer between your agents and this server.