fix: validate_tool_arguments does not enforce Literal/const constraints on tool fields

[JessicaHe22]

Pull Request

Issue

Fixes #1106

Description

The issue #1106 identified two independent gaps where Literal[...] constraints on tool fields were silently dropped.

Gap A — validator ignores const on discriminated union tag fields
Already fixed in previous PR. This PR adds a test (test_strict_rejects_invalid_discriminator_value) to explicitly assert that a discriminator value matching no branch (e.g. kind: "horse" when only "cat" and "dog" are defined) is rejected under strict=True.

Gap B — enum keyword dropped for plain Literal[...] fields
Fixed in this PR with two changes:

convert_function_to_ollama_tool: the simple-type flattening branch was discarding the enum array that Pydantic emits for Literal fields. It now carries enum forward onto the output schema so the LLM sees the allowed values.

_build_pydantic_type_from_schema: the simple-type fallback was mapping any type: string field to plain str, ignoring enum and const. It now maps enum → Literal[V1, V2, ...] and const → Literal[V] before falling through to the bare type lookup, so Pydantic enforces the constraint during validation.

Testing

• Tests added to the respective file if code was changed
• New code has 100% coverage if code was added
• Ensure existing tests and github automation passes (a maintainer will kick off the github automation when the rest of the PR is populated)

Attribution

• AI coding assistants used

---

Adding a new component, requirement, sampling strategy, or tool?

If your PR adds or modifies one of the types below, check the matching box. A checklist of type-specific review items will be posted as a comment.

• Component
• Requirement
• Sampling Strategy
• Tool

NOTE: Please ensure you have an issue that has been acknowledged by a core contributor and routed you to open a pull request against this repository. Otherwise, please open an issue before continuing with this pull request.

[AngeloDanducci]

Hi Jessica, thanks for the PR!

Overall I think this looks pretty good. Are single value constraints handled as well? I have a suggestion for an additional test to verify.

You will want to install the pre-commit hooks to use in the future (I see you fixed a ruff format problem). Additionally you need to sign off on your commits. To fix this you can do the following:

To add your Signed-off-by line to every commit in this branch:

    Ensure you have a local copy of your branch by [checking out the pull request locally via command line](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/checking-out-pull-requests-locally).
    In your local branch, run: git rebase HEAD~2 --signoff
    Force push your changes to overwrite the branch: git push --force-with-lease origin jessicah/issue-1106

In the future when you commit if you use an -s flag in your git commit commands ie git commit -s -m "commit message" you won't have to do the above. If you have any issues with this let me know and we can work around it.

[AngeloDanducci]

I think it's worth adding a test for single value constraints.

Suggested change

	assert result["mode"] == "read"
	assert result["mode"] == "read"
	def test_strict_rejects_value_outside_single_value_literal(self):
	"""A single-value Literal[...] (emitted as const) must also be enforced."""
	from typing import Literal
	from pydantic import ValidationError
	def tag_op(name: str, kind: Literal["cat"]) -> str:
	"""Tag something.
	Args:
	name: the name
	kind: the kind
	"""
	return "ok"
	mt = MelleaTool.from_callable(tag_op)
	# The allowed value must survive into the schema the backend sees.
	props = mt.as_json_tool["function"]["parameters"]["properties"]
	assert props["kind"].get("enum") == ["cat"]
	with pytest.raises(ValidationError):
	validate_tool_arguments(
	mt, {"name": "Bob", "kind": "horse"}, strict=True
	)